Category: FIDO & Passkeys

Platform Authenticator

Also known as: Internal Authenticator

Simply put

A platform authenticator is an authentication component built directly into a device, such as a laptop or smartphone, that securely stores login credentials and performs the cryptographic operations needed to sign in. It typically relies on the device's built-in features, like biometric sensors or a hardware-protected key store, to verify the user. Because it is tied to a specific device, it is used to prove identity from that device rather than being carried between systems.

Formal definition

In the WebAuthn model, a platform authenticator is an authenticator that is integrated into a client device (as opposed to a roaming or cross-platform authenticator such as an external security key). It manages FIDO credentials and performs private-key cryptographic operations, typically backed by the device's hardware-protected key store, and commonly uses local user verification mechanisms such as biometric sensors or a device PIN. Platform authenticators are one of the mechanisms used to create and exercise FIDO credentials, including passkeys, in authentication ceremonies; they perform authentication (verification of a principal) and are distinct from authorization decisions. Specific capabilities, such as which user verification methods are supported and how credentials are protected or synced, depend on the device, operating system, and configuration, and the precise interoperability behavior is defined by the applicable WebAuthn and FIDO specifications rather than restated in full here.

Why it matters

Platform authenticators are central to the industry shift toward phishing-resistant, FIDO-based authentication. Because the credential's private key is bound to a specific device and typically backed by a hardware-protected key store, the secret used to sign in is not transmitted to or stored by the relying party in a reusable form. This changes the threat model compared to shared secrets such as passwords: an attacker who cannot exercise the local user verification on the device generally cannot complete the authentication ceremony, even if they compromise server-side data.

For organizations, platform authenticators lower the friction of strong authentication because they reuse capabilities users already have, biometric sensors or a device PIN, rather than requiring a separately provisioned hardware token. This makes them a practical mechanism for creating and exercising FIDO credentials, including passkeys, across a broad device base. At the same time, the device-bound nature is a design constraint that architects must plan around: because a platform authenticator proves identity from a particular device, deployments need account recovery and enrollment strategies for lost, replaced, or additional devices.

It is important to keep scope precise. A platform authenticator performs authentication, the verification of a principal, and is distinct from authorization decisions about what that principal may then do. Its specific behavior, including which user verification methods are supported and how credentials are protected or synced, depends on the device, operating system, and configuration, so security teams should validate capabilities against the applicable WebAuthn and FIDO specifications and their own vendor's implementation rather than assuming uniform behavior.

Who it's relevant to

Security Architects

Architects evaluating phishing-resistant authentication need to understand where platform authenticators fit relative to roaming authenticators and how their device-bound nature affects enrollment, recovery, and coverage across a device fleet. Because supported user verification methods and credential protection vary by device, OS, and configuration, capabilities should be validated against the applicable WebAuthn and FIDO specifications rather than assumed.

IAM Engineers

Engineers implementing WebAuthn-based sign-in work directly with platform authenticators as one mechanism for creating and exercising FIDO credentials, including passkeys. They handle registration and authentication ceremonies, local user verification behavior, and the distinction between platform (built-in) and cross-platform (roaming) authenticators when configuring relying party requirements.

System Administrators

Administrators managing endpoints and user enrollment must account for the fact that a platform authenticator proves identity from a specific device. This shapes support processes for lost, replaced, or additional devices, and requires attention to how the device's built-in features, such as biometric sensors or a device PIN, are used for local user verification.

Compliance Officers

Those assessing authentication controls should recognize that platform authenticators perform authentication, verification of a principal, and are distinct from authorization decisions. When documenting factor strength and credential handling, they should note that specific protections depend on the device, operating system, and configuration rather than assuming uniform behavior across deployments.

Inside Platform Authenticator

Embedded authenticator

A platform authenticator is a FIDO2/WebAuthn authenticator that is built into a device such as a laptop, phone, or tablet, rather than being a separate roaming (cross-platform) device like a security key. It is bound to the specific device on which it resides.

Inherence and possession factors

Platform authenticators typically combine a possession factor (the device itself) with a local user verification step that is often an inherence factor (biometric such as fingerprint or facial recognition) or a knowledge factor (device PIN). The user verification is performed locally and is not transmitted to the relying party.

Private key storage

The authenticator generates and stores the WebAuthn credential private key in the device's protected hardware, such as a secure enclave or TPM, depending on the platform. Only the corresponding public key is registered with the relying party.

Relationship to WebAuthn and passkeys

Platform authenticator is a role defined within WebAuthn (the W3C browser API in the FIDO2 set of specifications). Credentials created by a platform authenticator may be device-bound or, when synced across a user's devices, are commonly referred to as passkeys. Platform authenticator and passkey are related but not synonymous terms.

Common questions

Answers to the questions practitioners most commonly ask about Platform Authenticator.

Is a platform authenticator the same thing as a passkey?

No, though the terms are often conflated. A platform authenticator is a FIDO2/WebAuthn authenticator that is built into a device (such as a laptop or phone) rather than being a removable roaming authenticator. A passkey is a WebAuthn credential, typically a discoverable (resident) credential, that may be stored on and used through a platform authenticator. In most deployments a passkey can also be synced across devices or used via a roaming authenticator, so the platform authenticator is one possible home for a passkey rather than a synonym for it.

Does using a platform authenticator mean the user is authenticated with a single biometric factor only?

Not exactly. The biometric or PIN presented to a platform authenticator is typically a local user verification gesture that unlocks the private key held on the device; it is not transmitted to the relying party. The authentication asserted to the relying party is based on possession of the device-bound private key (a possession factor), with the local gesture (inherence or knowledge) providing user verification. Whether this is treated as multi-factor depends on the standard profile and how the relying party interprets user verification and user presence signals.

How does a relying party distinguish a platform authenticator from a roaming authenticator during registration?

During WebAuthn registration a relying party can express a preference through the authenticatorSelection criteria, including the authenticatorAttachment value (typically 'platform' versus 'cross-platform'). This is a preference and hint rather than a strict guarantee in all cases, and actual enforcement depends on the browser, operating system, and authenticator behavior. Depending on configuration, attestation data may provide additional signals, though attestation availability and content vary by platform.

Should we require user verification when relying on a platform authenticator?

This depends on your assurance requirements. In WebAuthn the relying party can set userVerification to 'required', 'preferred', or 'discouraged'. Requiring user verification typically means the local biometric or PIN gesture must succeed, which supports treating the ceremony as multi-factor. Setting it lower may improve friction but reduces assurance. The appropriate choice depends on the sensitivity of the resource and your organization's authentication assurance policy, and behavior can vary across authenticators and platforms.

How should we handle account recovery when credentials are bound to a platform authenticator?

Because a device-bound credential on a platform authenticator is typically not portable, losing or replacing the device can lock a user out of that specific credential. In most deployments you should register more than one authenticator per account, such as an additional platform authenticator on another device or a roaming authenticator, and maintain a defined recovery path. Whether credentials sync across a user's devices depends on the platform and credential type; where syncing is unavailable, recovery planning is more critical. Recovery process design is largely an operational and policy concern rather than something the WebAuthn standard itself prescribes.

Can a single platform authenticator serve users across multiple relying parties and browsers?

A platform authenticator can hold credentials scoped to multiple relying parties, since WebAuthn credentials are bound to a specific relying party identifier. However, whether those credentials are accessible across different browsers on the same device depends on how the operating system and browsers share access to the underlying authenticator and credential store, which varies by platform and configuration. You should not assume seamless cross-browser availability without testing in your target environments.

Common misconceptions

A platform authenticator and a passkey are the same thing.

Platform authenticator refers to the WebAuthn authenticator role built into a device, while passkey commonly refers to a WebAuthn credential, particularly one that is synced across devices. A platform authenticator can hold device-bound credentials or passkeys, so the terms describe different aspects and are not interchangeable.

The biometric used by a platform authenticator is sent to the server to authenticate the user.

In most deployments the biometric or PIN is used only for local user verification on the device and is never transmitted to the relying party. Authentication to the relying party is completed by a signature produced with the private key held in the device.

A platform authenticator by itself only proves possession, so it is single-factor.

A platform authenticator typically combines a possession factor (the device) with a local user verification step (biometric or PIN), so a single WebAuthn ceremony can satisfy multiple factors depending on configuration. Whether user verification is required is set by the relying party's WebAuthn options.

Best practices

Set the WebAuthn authenticatorSelection criteria explicitly (for example requiring platform attachment and user verification) when you intend to enroll platform authenticators rather than roaming keys.

Require userVerification when you need the local biometric or PIN check, and treat the resulting credential as combining possession and a verification factor rather than assuming it is single-factor.

Distinguish device-bound credentials from synced passkeys in your enrollment and recovery design, since sync behavior affects where the private key can be used.

Provide and document account recovery and backup authenticator options, because a purely device-bound platform authenticator is tied to a single device that can be lost or replaced.

Encourage or require registration of more than one authenticator per user so that loss of a device does not lock the user out.

Validate the relying party's handling of attestation and public key registration during enrollment, and confirm that only the public key, not any biometric data, is stored server-side.