WebAuthn, FIDO, and passkeys

WebAuthn and FIDO provide authentication mechanisms. Check the authenticator, relying party, account recovery and application permissions when using passkeys for administration.

Overview#

Web Authentication (WebAuthn) lets a relying party authenticate users with origin bound public key credentials through a user agent and authenticator. FIDO Client to Authenticator Protocol (CTAP) defines communication between a platform/client and external or platform authenticators. “Passkey” commonly describes a discoverable FIDO credential that may be device bound or available across a provider ecosystem. WEBAUTHN 2 FIDO 23

These technologies can strongly protect administrative sign in. They don't identify a person without an enrolment/proofing process, decide what the person may do, or act as a physical PACS credential merely because an authenticator uses biometrics, NFC, BLE, or a secure element.

Standards status#

Status labels matter when writing procurement requirements or compatibility claims.

WebAuthn and CTAP revisions are related but have separate status, implementation, and certification lifecycles. A browser supporting a WebAuthn feature doesn't prove every authenticator/CTAP transport supports the corresponding capability. WEBAUTHN 3 FIDO 23 FIDO 231

Architecture and trust boundaries#

relying-party server
  <-> HTTPS origin and user agent
       <-> platform WebAuthn implementation
            <-> platform or roaming authenticator via CTAP/platform API

• The relying party (RP) defines the RP ID, allowed origins, account binding, challenge, credential policy, and server side verification.
• The client/user agent mediates the WebAuthn ceremony and reports client data including challenge, origin, and ceremony type.
• The authenticator creates and uses a credential scoped to the RP ID, performs user presence and possibly user verification, and returns authenticator data plus an attestation statement or assertion signature.
• The identity/lifecycle system determines who may enrol, how accounts are recovered, and when credentials and sessions are revoked.
• The application authorisation layer decides which tenant, site, resource, and operation an authenticated account may access.

Authentication success means the presented credential satisfied the RP’s ceremony policy. It doesn't prove the operator’s current employment, physical location, intent, or authority for a specific unlock, lockdown, evidence export, credential issuance, or configuration change.

Registration ceremony#

The server should create registration options for an already authenticated, authorised enrolment context. Bind the ceremony to the intended account and session.

Server side registration checks#

1. Generate an unpredictable, single use challenge and retain its account/session/purpose/expiry binding.
2. Set the expected RP ID and user identity; keep the stable user handle opaque and free of unnecessary personal data.
3. Choose authenticator attachment, discoverable credential, user verification, attestation, and algorithm policy deliberately.
4. On response, parse with strict size/shape limits and reject duplicate security critical members.
5. Verify client data type, challenge, and exact allowed origin.
6. Verify RP ID hash, required user presence/user verification flags, and ceremony specific authenticator data.
7. Validate the attestation statement only to the level required by policy; otherwise apply the selected privacy preserving attestation conveyance policy.
8. Confirm the public key algorithm is allowlisted and store the credential ID, public key, user handle/account, sign count where used, transports as hints, backup related state where available, and policy evidence.
9. Prevent credential ID collision/account confusion and audit enrolment without storing reusable ceremony secrets.

Don't allow a session authenticated only with a weak or recovered factor to silently enrol a stronger credential without step up and notification appropriate to the account’s consequence.

Authentication ceremony#

For authentication, issue a new bounded challenge and verify the returned assertion at the server.

• Match the response to the intended RP, account/discoverable login context, session, purpose, and expiry.
• Verify type, challenge, and exact origin in client data.
• Verify RP ID hash and required user presence/user verification flags.
• Select the stored public key by credential ID under the correct tenant/RP/account relationship.
• Verify the signature over the prescribed authenticator data and client data hash construction.
• For discoverable credentials, validate the returned user handle under the RP’s account mapping rules.
• Process signature counter behaviour according to authenticator capabilities; a non incrementing counter isn't by itself proof of cloning, and an unexpected regression needs risk handling rather than an unsafe universal response.
• Consume the challenge once, even when later authorisation fails.

Create a new application session after success. Authentication doesn't remove the need for secure session cookies, CSRF protection, reauthentication, authorisation, rate limits, and audit.

RP ID, origin, and domain governance#

WebAuthn phishing resistance depends heavily on browser enforcement plus correct RP/origin configuration.

• Maintain an exact allowlist of HTTPS origins; development and production origins are separate trust domains.
• Choose the RP ID at the narrowest domain scope that supports the intended applications. A broad registrable domain RP ID can expand which compromised subdomains matter.
• Protect DNS, domain registration, TLS, reverse proxies, redirects, hosting, and all origins allowed to initiate ceremonies.
• Don't accept an origin because it ends with a trusted string; parse and compare scheme, host, and port under Web origin rules.
• Treat native application and related origin features as explicit profiles with platform/version testing and change control.
• Reassess credentials before domain migration, merger, tenant split, or relying party rebranding; RP ID binding is intentional and can't be wished away by redirect.

User presence, user verification, and biometrics#

User presence (UP) indicates that the authenticator performed a user presence test, commonly through an explicit gesture. User verification (UV) indicates that the authenticator locally verified the user through a configured method such as a PIN or biometric. The RP must request and check the policy it requires.

WebAuthn normally receives a UV result, not a raw biometric. A platform biometric used to unlock a passkey isn't the same system, template, assurance, liveness, retention regime, or legal purpose as a PACS biometric reader. Keep them in separate privacy, assurance, and lifecycle assessments.

UV doesn't identify which authorised person used a shared device unless enrolment and device/account policy establish that relationship. User presence alone doesn't prove informed approval of the application transaction.

Passkeys and credential characteristics#

A passkey may be:

• a discoverable credential usable in usernameless/identifier first experiences;
• bound to one authenticator/device;
• backed up or synchronised within a platform/provider ecosystem;
• usable through cross device/hybrid authentication without being copied into the initiating device.

Don't infer device bound hardware assurance merely from the word “passkey.” If policy differentiates device bound and backed up credentials, use defined WebAuthn flags/metadata and product support; document what happens when the information is absent or changes.

Synchronization can improve recovery and multi device usability but moves assurance into the provider account, device enrolment, sync encryption, recovery, and ecosystem controls. A hardware security key may offer different portability and recovery properties. Provide more than one approved authenticator for privileged accounts so loss doesn't force a weak emergency bypass.

Attestation and authenticator policy#

Attestation can provide evidence about an authenticator model or provenance under a selected format and trust policy. It is optional in many deployments and can create privacy/correlation and operational risks.

• Define whether no attestation, self/none, indirect, direct, or enterprise attestation is acceptable.
• Validate the complete attestation format and trust chain when a policy depends on it.
• Maintain metadata/trust anchor update, revocation/status, model allow/deny, and rollback procedures.
• Don't treat attestation as proof of the person’s identity or current device health.
• Plan for model retirement and replacement without locking operators out.
• Minimize persistent authenticator identifiers; enterprise attestation needs explicit governance and user/workforce notice.

FIDO certification, authenticator metadata status, platform support, and an organization’s risk acceptance are separate facts. Record each rather than collapsing them into “FIDO compliant.”

CTAP and authenticator management#

CTAP covers client to authenticator operations and transports. It doesn't authorise the relying party application.

• Establish an approved authenticator inventory and ownership/replacement process.
• Require appropriate authenticator PIN/UV and retry/lockout policy; protect against shoulder surfing and help desk social engineering.
• Bound resident/discoverable credential capacity and handle storage full conditions safely.
• Control enterprise attestation, credential management, reset, and firmware/update capabilities.
• Treat USB, NFC, BLE, and hybrid transport availability as attack surface and usability decisions; disable only with tested recovery alternatives.
• A factory reset can remove credentials but doesn't close application sessions or prove provider synchronised copies are unavailable.

Transport presence, especially BLE or NFC proximity, isn't sufficient transaction or operator authorisation.

Cross device authentication#

Cross device flows let an operation initiated on one device be authorised or authenticated using another. RFC 10027 documents security guidance for these flows. CROSS DEVICE

• Clearly identify the initiating service, target account, and action on the authorizing device.
• Bind the secondary device result cryptographically and temporally to the exact initiating transaction.
• Use high entropy, short lived, single use secrets; never encode bearer authorisation into a reusable QR code.
• Prevent session swapping, remote phishing, unsolicited prompts, and acceptance into the wrong browser/session.
• Treat QR, BLE/proximity, deep links, and push notifications as transport/discovery signals, not standalone identity proof.
• Avoid exposing QR codes or recovery artefacts on monitored displays, support captures, recordings, or screen sharing sessions.
• Expire abandoned initiations and show both devices an unambiguous completion/failure state.

For a high impact physical security action, cross device authentication can be a step up factor but must still bind the local authorisation decision to tenant, resource, operation, prerequisites, reason, and expiry.

Account recovery and lifecycle#

The weakest recovery path often controls the effective assurance of the account.

• Enroll at least two approved authenticators or a governed recovery method for privileged operators.
• Require strong verification and independent notification before adding or replacing authenticators.
• Rate limit and delay high risk recovery where operationally acceptable; protect against help desk impersonation.
• Let users and administrators view credential creation/last use/type information without exposing tracking sensitive details.
• Revoke lost credentials, active sessions, refresh tokens, application passwords, and recovery artefacts as separate actions.
• Define joiner/mover/leaver and role change propagation from the authoritative identity source.
• Retain security audit evidence according to policy after credential deletion without retaining unnecessary personal data.

If the identity provider or passkey ecosystem is unavailable, preserve an engineered local recovery path for authorised administration. Never make certified egress or life safety operation depend on WebAuthn availability.

Physical security application profile#

Recommended uses include operator sign in, privileged administration, evidence export approval, credential management step up, and access to cloud management consoles. Keep application authentication separate from physical credential presentation:

WebAuthn assertion -> operator application session
  -> application authorization for a scoped operation
  -> separately governed PACS/VMS/alarm request
  -> downstream acknowledgement and observed outcome

A WebAuthn authenticator isn't automatically an OSDP smart card credential, mobile access key, door token, or proof that a person passed through a portal. Likewise, WebAuthn success must not directly trigger a relay or unlock without the application’s high impact command controls.

Privacy, logging, and monitoring#

Log account/tenant, credential record ID in an internal non public form, ceremony type, RP/origin decision, UP/UV policy result, attestation policy outcome, authenticator metadata/policy revision where relevant, recovery/admin actor, session/correlation ID, and authorisation outcome. Don't log challenges before expiry, client data wholesale, assertion signatures, credential public key material unnecessarily, PINs, biometric data, QR contents, or session tokens.

Monitor enrolment and deletion, repeated challenge failures, origin/RP mismatch, signature failure, unknown credential IDs, abnormal recovery, metadata status changes, privileged step up failure, and credentials used after reported loss.

Review checklist#

• Normative baseline identifies WebAuthn Level 2 versus non final Level 3 and exact CTAP status
• RP ID and allowed origins are minimal, exact, governed, and protected with DNS/TLS/hosting controls
• Registration challenge, account/session binding, algorithm, attestation, UP/UV, and credential storage policy defined
• Authentication verifies type, challenge, origin, RP ID hash, flags, user handle, signature, and replay
• Discoverable, device bound, backed up/synchronised, and cross device credential behaviour distinguished
• Attestation, metadata, certification, revocation/status, privacy, and model retirement governed
• Recovery is no weaker than intended assurance; multiple authenticators and session/token revocation are addressed
• Cross device flow binds the authorizing device to the exact initiating context and resists phishing/session swapping
• WebAuthn authentication kept separate from local role, object/action, PACS, and physical outcome authorisation
• Logs exclude ceremony secrets, tokens, biometric data, and tracking sensitive authenticator details

Sources#

• WEBAUTHN 2, Web Authentication: An API for accessing Public Key Credentials Level 2, W3C Recommendation.
• WEBAUTHN 3, Web Authentication: An API for accessing Public Key Credentials Level 3, W3C Candidate Recommendation Snapshot, 26 May 2026; non final.
• FIDO 23, FIDO Alliance specifications: CTAP 2.3 Proposed Standard, FIDO Alliance, 26 February 2026.
• FIDO 231, Client to Authenticator Protocol 2.3.1 Working Draft, FIDO Alliance, 29 May 2026; non final.
• CROSS DEVICE, RFC 10027 / BCP 247: Best Current Practice for Security of Cross Device Flows, IETF, August 2026.

Section overview · Wiki home