Share via

What is the security boundary of Windows Hello KeyCredentialManager credentials for desktop apps?

Roman Prudchenko 0 Reputation points
2026-06-05T06:53:21.1+00:00

I am evaluating Windows Hello / KeyCredentialManager for a desktop application that protects high-value local secrets encrypted at rest. The application creates a local master key and stores it encrypted. One unlock path is password-based. Another unlock path uses Windows Hello through KeyCredentialManager and related WinRT APIs.

Common scenario:

  1. The application creates a KeyCredential with a credential name.
  2. Another process running under the same Windows user account attempts to open the same credential name.
  3. Windows shows a Windows Hello user verification prompt.
  4. If the user approves the prompt, the second process can perform cryptographic operations with that credential.

I am trying to understand whether this is expected behavior and what the intended security boundary is.

Questions:

  1. Is KeyCredentialManager scoped to the Windows user account or current application, that requests access to credentials?
  2. Is it expected that another process under the same user account can open the same KeyCredential if the credential name is known?
  3. Does KeyCredentialManager provide any app-level isolation for classic desktop applications? And how to implement such approach if yes?
  4. Does AppContainer or Win32 App Isolation change behavior from Q3?
  5. Is there a supported way to bind a KeyCredential to a specific executable, publisher or package identity?
  6. Is the credential name supposed to be treated as a secret?
  7. Does TPM backing or key attestation change the local same-user threat model?
  8. For applications protecting password-vault local secrets, does Microsoft recommend using Windows Hello as the only unlock mechanism, or only as one factor in a broader design?

Expected outcome: I am looking for an explanation of the intended security boundary of KeyCredentialManager and the recommended architecture for protecting high-value local secrets.

Relevant APIs:
KeyCredentialManager.RequestCreateAsync
KeyCredentialManager.OpenAsync
KeyCredential.RequestSignAsync
Windows.Security.Credentials
Windows.Security.Cryptography

Windows development | Windows API - Win32
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator
    2026-06-05T09:14:24.2466667+00:00

    Hello @Roman Prudchenko ,

    I have carefully reviewed the scenario you described, and I would like to share some perspectives and relevant documentation to help us analyze this issue together. Based on the current Windows system architecture, I would like to offer some suggestions and observations regarding your questions:

    1 & 2. Scope of KeyCredentialManager and Cross-process behavior

    According to the architectural documentation for the pure (unpackaged) Win32 environment, it appears that the security boundary is generally established at the User Account level rather than the application level. In this traditional environment, processes running under the same user typically share a common privilege space. Therefore, the fact that another process can request to open a KeyCredential if it knows the credential name is likely an anticipated behavior, as the operating system might not differentiate between two Win32 processes belonging to the same user.

    3 & 4. App Isolation, AppContainer, and MSIX

    To establish isolation at the application level, Microsoft often suggests granting the application an App Identity. If your application is not running within an AppContainer, it may struggle to protect itself from other same-user processes. If you utilize packaging such as MSIX or adopt the new Win32 App Isolation mechanisms, I believe this behavior might change. In those cases, the system seems to evaluate access rights based on the Package Family Name (PFN), which helps keep credentials isolated per application rather than shared entirely at the user level.

    5. Binding to an executable or package identity

    In case you want to "bind" the credential to a specific application, identifying it via package identity (e.g., through MSIX) seems to be the most frequently mentioned solution in the documentation. For standalone, unpackaged .exe files, there is probably no standard mechanism supported by the OS to tightly bind this API solely to that specific executable.

    6. Secrecy of the Credential Name

    Microsoft's documentation might not explicitly state that the credential name must be an absolute secret. Even though malware could potentially discover it, relying on hiding this name (security through obscurity) perhaps shouldn't be your core defense layer. Nevertheless, generating a random name could be considered a mitigating measure to reduce the attack surface.

    7. TPM and Key Attestation

    The presence of a TPM chip and key attestation is typically intended to ensure that the key material cannot be extracted or exported off the physical device. However, it might not resolve the "Confused Deputy" problem at the software level. This means that if a valid cryptographic request is sent by malicious code running under the same user privileges, the TPM would likely still process the operation because it cannot distinguish process boundaries in an environment without an AppContainer.

    8. Advice on Defense-in-depth architecture

    For applications protecting high-value local secrets (like a password vault), I think relying solely on a single layer of protection (Windows Hello in an unpackaged Win32 environment) could carry potential risks if the device is compromised by same-user malware. A safer approach would perhaps be adopting a "Defense in depth" model. You might consider using Windows Hello as a convenient unlock method while combining it with boundaries like MSIX packaging, or requiring a master password periodically to mitigate risks.

    I hope the information and documents above can provide additional perspectives for your architectural evaluation. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

    Thank you.

    Was this answer helpful?

  2. AI answer

    2026-06-05T06:54:00.42+00:00

    KeyCredentialManager and Windows Hello are designed as user- and device-scoped credentials, not as per-executable secrets. The primary security boundary is the Windows user account and device, with user verification (PIN/biometric) as the second factor. App-level isolation is provided for UWP/packaged apps via the Windows Hello APIs, but classic desktop apps must treat KeyCredential as one component in a broader design.

    Direct answers to the questions:

    1. Scope of KeyCredentialManager (user vs. app) KeyCredentialManager creates a public/private key pair that is bound to the device and the user, not to a specific process. Windows Hello credentials are “based on certificate or asymmetrical key pair” and “bound to the device,” and authentication is two-factor: a key tied to the device plus PIN/biometric.

    For apps, the Windows Hello layer exposes APIs such as KeyCredentialManager.RequestCreateAsync and KeyCredential.RequestSignAsync. The private key never leaves the secure store/TPM, and apps only request operations (for example, signing) via these APIs.

    1. Other processes under same user opening the same KeyCredential The model described in the context assumes that a user’s keys are available to applications (via the Windows Hello APIs) once the user has performed the required gesture. The keys are “used to sign requests that are sent to the identity provider,” and applications “can use specific APIs to request operations that require key material for particular actions.”

    The documentation explicitly notes that:

    • The private key is not exposed to the application.
    • The user gesture (PIN/biometric) is used to “release the key,” after which applications can use the key via APIs.

    This aligns with the behavior where another process under the same user, knowing the credential name, can request operations with that key after Windows Hello user verification. The boundary is the user + device + gesture, not the individual process.

    1. App-level isolation for classic desktop apps The context states that “an application can never use the keys from another application, nor can someone ever use the keys from another user,” but this is in the Windows Hello app model context (UWP/packaged apps using the Windows Hello APIs). The isolation is enforced by the Windows Hello layer and the way keys are associated with identities and apps.

    For classic desktop apps, the documentation does not describe a separate, stronger per-executable isolation boundary beyond the Windows Hello API model. Instead, it emphasizes:

    • Keys are bound to the device and user.
    • Apps call APIs to request signing/decryption; the Windows Hello layer mediates access.

    There is no additional, documented per-executable binding mechanism in the provided context for Win32 desktop apps using KeyCredentialManager.

    1. Effect of AppContainer or Win32 App Isolation The context does not describe any change in KeyCredentialManager behavior specific to AppContainer or Win32 App Isolation. The described behavior and examples are for UWP/packaged apps and their backend services, where keys are per-user, per-device, and accessed via the Windows Hello APIs.
    2. Binding a KeyCredential to a specific executable, publisher, or package identity The documentation describes binding keys to:
    • The device and user (Windows Hello registration), and
    • The app’s account model (for example, storing multiple keys per user, per device, in the backend).

    It does not describe a supported mechanism to bind a KeyCredential to a specific executable, publisher, or package identity in the way code-signing or AppLocker policies do. Instead, it focuses on:

    • Creating keys via KeyCredentialManager.RequestCreateAsync(AccountId, ...), where AccountId is an app-level identifier.
    • Using those keys for challenge–response authentication to a backend.
    1. Whether the credential name should be treated as a secret The examples treat the credential identifier (AccountId) as an account identifier (for example, email address or username) that is stored and used by the app and backend. The credential name/identifier is not described as a secret; it is part of the registration data sent to the backend and stored in a database schema that includes user ID, device ID, and public key.

    Because the public key and identifiers are stored server-side and used for authentication, the credential name should be treated as an identifier, not as a secret.

    1. TPM backing or key attestation and same-user threat model TPM and attestation address hardware trust and server-side assurance:
    • Windows Hello “creates a set of public/private key pairs and writes the private keys to the device’s Trusted Platform Module (TPM) chip.”
    • The app can obtain “optional key attestation information to acquire cryptographic proof that the key is generated on the TPM.”

    This strengthens protection against key extraction and provides proof to the backend that the key is hardware-backed. However, it does not change the local same-user threat model in terms of process-level access: once the user has authenticated with Windows Hello, the Windows Hello layer can use the TPM to perform cryptographic operations on behalf of the user. TPM/attestation do not introduce a per-process boundary; they harden key storage and remote trust.

    1. Use of Windows Hello for password-vault local secrets The documentation positions Windows Hello as a strong 2FA mechanism that replaces reusable passwords with “the combination of a specific device, and a biometric gesture or PIN.” It is conceptually similar to smart cards, using cryptographic primitives and keys in tamper-resistant hardware.

    For app design:

    • Windows Hello is used to authenticate the user and to sign challenges for backend services.
    • For local secrets, the pattern is: generate a key pair via Windows Hello, store the public key and optional attestation in the backend, and use challenge–response to authenticate.

    The context does not prescribe that Windows Hello must be the only unlock mechanism for local password vaults. It describes:

    • Using Windows Hello as the primary authentication mechanism for new systems.
    • For migrations, initially keeping username/password and then optionally disabling them once Windows Hello is fully adopted.

    Recommended architectural pattern from the context

    From the provided material, the intended security and architectural pattern is:

    • Device- and user-bound keys
      • Each device creates a unique key pair per user and per account.
      • The private key is stored in TPM or secure software storage and never exposed.
    • App and backend integration
      • The app uses KeyCredentialManager.RequestCreateAsync(AccountId, ...) to create a key.
      • The app sends the public key (and optional attestation) plus a device identifier to the backend.
      • The backend stores multiple keys per user to support multiple devices.
    • Authentication via challenge–response
      • The backend sends a challenge.
      • The app calls KeyCredential.RequestSignAsync to sign the challenge.
      • Windows Hello prompts for PIN/biometric and uses the TPM to sign.
      • The backend verifies the signature using the stored public key.
    • Isolation and protection
      • The Windows Hello layer mediates access to key operations and requires user gestures where appropriate.
      • The app never handles private key material directly.
      • For high-value secrets, combine Windows Hello-based authentication with backend policies (for example, device management, revocation, and multiple keys per user) rather than relying solely on local process isolation.

    In summary, KeyCredentialManager’s primary boundary is the user + device + Windows Hello gesture, with keys protected by TPM or secure storage and accessed only via Windows Hello APIs. It is not documented as a per-executable isolation mechanism for classic desktop apps, and high-value local secrets should be protected using Windows Hello as part of a broader design that includes backend verification and careful handling of identifiers and keys.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.