Enterprise Policy and Compliance Controls

Passkeys change what a compliance matrix can honestly claim. Some controls that were previously aspirational become mechanically enforced; others that sound reasonable turn out to have no protocol mechanism behind them at all. This page covers which controls are checkable, how to trace a written requirement to an auditable check, and where the common frameworks actually land. It sits under Backend Verification and Secure Credential Storage.

Concept Definition and Spec Grounding

A control is only meaningful if something checks it and something records that the check ran. WebAuthn provides a small set of fields that support this directly: the origin, which the browser enforces before your code sees anything; the user-verification flag, which reports whether the authenticator verified a human; the backup bits, which describe whether the credential can leave the device; and attestation, which — when present and verified — describes the authenticator model.

Everything else in a typical enterprise control list is either derived from those, or is not a WebAuthn control at all. “Multi-factor authentication” is a claim about the ceremony, satisfied when the authenticator verified a user and the credential is hardware-held. “Credentials must not be shared” is a property of the key material, guaranteed by the authenticator rather than checked by you. “Access must be revocable within N minutes” is a session-management property with nothing to do with the protocol.

The distinction matters because auditors ask for evidence. A control that maps to a field you check and log is demonstrable in minutes. A control that maps to an assumption is a conversation, and usually a longer one than anybody planned for.

Which controls are technically enforceable A compliance matrix is only useful if every control in it corresponds to something the protocol can actually check. The last two are where most control matrices overstate what is possible phishing resistance origin binding — enforced by the browser, always user verification required the UV flag, checked server-side per action certified hardware only attestation plus metadata — enrolment-time policy credential must not be synced only via attestation and managed devices device identity only via enterprise attestation on managed fleets

Architecture and Data Flow

The enforcement points are few and worth naming precisely. The browser enforces the origin boundary before a ceremony begins; nothing you do affects it and nothing an attacker does defeats it. The authenticator enforces key custody and, where it can, user verification. Your server enforces everything else: which credentials are acceptable at enrolment, which flags are required for which actions, how long a session survives, and how quickly a revocation takes effect.

That division is what a control matrix should reflect. Controls enforced by the browser are the strongest claims you can make, because they hold regardless of your own code quality. Controls enforced by the authenticator depend on which authenticator, which is why attestation exists. Controls enforced by your server are as good as your implementation and your tests, which is where the audit effort should concentrate.

The evidence trail follows the same shape. Origin failures are effectively never seen in production, so their absence is the evidence. Verification-flag decisions are recorded per session. Enrolment policy decisions are recorded per credential. Session revocation reach is a measured number rather than a claim.

From a requirement to a checkable control Every claim in a matrix should trace to a specific field checked at a specific moment. Four columns; most matrices stop at two requirement written, from a framework mechanism a protocol field or property check where and when it runs evidence what your logs record A requirement with no fourth column cannot be demonstrated.

Implementation Guide

Step 1 — write the four-column matrix. Requirement, mechanism, where it is checked, what is recorded. Any row missing the fourth column is not yet a control.

Step 2 — record the assurance facts on the session. Which credential signed, whether the user was verified, and when. Without these, every per-action control has to re-derive its inputs and usually does not.

Step 3 — express action requirements as data. A table mapping action identifiers to required verification and maximum ceremony age, read by one middleware. Auditable in one place, and diffable when it changes.

Step 4 — record enrolment policy outcomes. Whether attestation was present, whether the model was recognised, and what tier the credential was assigned. This is the evidence for every hardware-related control.

Step 5 — measure the revocation window. Revoke a test credential, call a protected endpoint with the old session, and write down how long it kept working. That number is a control, and most organisations have never measured it.

Step 6 — document what is not enforceable. A matrix that quietly omits the controls you cannot check is worse than one that names them as compensating rather than preventive.

Validation Checklist

Assurance versus durability, again Compliance conversations conflate how strongly a user was verified with how likely their credential is to survive. Both belong in a matrix; they answer different questions assurance controls user verification required freshness of the last ceremony which credential signed step-up before sensitive actions resilience controls a second registered credential backup state of the primary the strength of the recovery path session revocation reach A framework asking about authentication strength means the left column; an auditor will ask about both.

Error Reference Table

Claim in a matrix Reality Better wording
“Credentials cannot be cloned” true for hardware-held keys; the counter detects some cases “Private keys are non-exportable; counter-based clone detection where supported”
“Passkeys are device-bound” false for synced credentials “Credentials may be synced; backup state is recorded per credential”
“We verify the device” only with attestation, and only to model level “Authenticator model is verified at enrolment where attestation is supplied”
“Sessions are revoked immediately” only if every request checks a store “Revocation takes effect within the access-token lifetime, measured at N minutes”
“MFA is enforced” depends on the user-verification flag being checked “User verification is required and verified server-side for the following actions”

Platform and Library Notes

Frameworks differ in how they treat a phishing-resistant single ceremony. Some treat an authenticator that verifies a user as satisfying a multi-factor requirement, on the basis that possession and verification are both present. Others require two distinct mechanisms regardless. This is a reading question rather than a technical one, and the productive contribution from an engineering team is a precise description of what the ceremony proves rather than an argument for a particular label.

Synced credentials are the other recurring point of friction. A framework written before passkeys existed may assume that a hardware-held credential is confined to one device, and a synced passkey is not. The honest position is that the private key remains non-exportable on every device that holds it, and that the set of devices is governed by the user’s platform account — which is a real difference and one that a reviewer is entitled to weigh.

Library support is largely irrelevant here. Every control in this area is either enforced by the browser, enforced by the authenticator, or implemented in your own application code.

Pitfalls and Security Hardening

1. Claiming device binding for synced credentials. The most common overstatement, and the easiest for a reviewer to disprove.

2. Listing clone detection as a mitigation. The signature counter is absent on most modern credentials; a matrix that relies on it is relying on something that mostly does not fire.

3. Omitting the recovery path. An account’s real strength is the weaker of sign-in and recovery, and a matrix covering only the first is measuring the wrong thing.

4. Treating attestation as an authentication control. It is an enrolment policy input, and it says nothing about any individual ceremony.

5. Asserting a revocation window nobody measured. It is a five-minute experiment and it frequently returns a surprising number.

6. Writing controls that cannot produce evidence. If an auditor asks “show me” and the answer requires reasoning rather than a query, the control is not yet implemented.

Frequently Asked Questions

Does a passkey count as two factors?

It depends on the framework’s wording, and the engineering answer should describe rather than assert. A ceremony where the authenticator verified a user combines possession of a non-exportable key with a verification the device performed. Whether that satisfies a particular definition of two factors is a reading of that definition, and stating the mechanism precisely is more useful than claiming the label.

Can we require that credentials are never synced?

Only through attestation on managed devices, and only for authenticators that support it. There is no request option that forbids syncing, and the backup bits report what happened rather than constrain it. A requirement written as a prohibition will need to become a preference plus an enrolment policy.

What evidence should we keep, and for how long?

Per-credential enrolment outcomes and per-session assurance facts, retained on the same schedule as your other authentication records. What you should not keep indefinitely is raw ceremony payloads: they contain identifiers and add nothing to the evidence once the outcome has been recorded.

How do we demonstrate phishing resistance?

By pointing at the mechanism rather than at a test result. Origin binding is enforced by the browser before your code runs, and a credential registered for your relying party cannot be surfaced to another origin. The supporting evidence is the absence of origin-mismatch events in your telemetry, which should be flat zero.

Do compliance controls apply to the recovery flow?

They should, and this is the gap most matrices have. Recovery is where an account’s real strength is decided, and a control set that assesses sign-in rigorously while treating recovery as an operational detail is measuring the strong half of the system.

Does any of this differ for machine-to-machine access?

Entirely. Passkeys are designed around a human touching a device, so service credentials remain shared secrets governed by rotation and scoping. A matrix should separate the two rather than implying that a passkey programme addressed both.

Rolling Passkeys Out Inside a Regulated Estate

The technical work in a regulated environment is the same as anywhere else; what differs is the order in which things have to be agreed, and getting that order wrong costs months.

Settle the assurance reading before writing code. Whether a single passkey ceremony satisfies your framework’s multi-factor requirement is a decision for whoever owns compliance, and it determines whether you need a second factor alongside the ceremony or not. Building first and asking afterwards produces a system that either carries pointless friction or fails a review.

Decide the synced-credential position early. If policy genuinely requires credentials that cannot leave a device, you are in the attestation-plus-managed-device world, with all the operational weight that implies: a trust store, a metadata dependency, an allow-list to maintain, and a procurement conversation about which authenticators are acceptable. If policy can accept synced credentials, almost all of that disappears. This single decision has more effect on delivery than any other.

Separate the populations. Employees on managed devices, contractors on their own hardware, and customers are three different control regimes, and trying to satisfy all three with one policy produces the worst of each. The tiered approach — everyone can enrol, some credentials unlock more — is usually how this resolves.

Plan the evidence before the audit. Every control needs a query that produces its evidence. Writing those queries while building is a few hours; reconstructing them under audit pressure from logs that were not designed for the purpose is a fortnight.

Treat recovery as in scope from the start. It is the control area most often deferred and the one an assessor will focus on, because it is where the account’s real strength is decided. A recovery flow designed after the sign-in flow has shipped tends to inherit whatever the old password reset did, which is rarely what anybody would have chosen deliberately.

Reading a Control Matrix Critically

Whether you are writing one or reviewing somebody else’s, four questions expose most of the weak rows quickly.

“What field is checked?” If the answer is not a named field in authenticatorData, clientDataJSON, an attestation statement or your own session record, the control is an assumption. Assumptions can be legitimate — key non-exportability is one — but they should be labelled rather than presented as checks.

“Where does the check run?” Browser, authenticator or your server. The three have very different strength characteristics, and a control enforced by the browser is worth more than one enforced by code you wrote, because it holds regardless of your own defects.

“What is recorded?” A check that leaves no trace cannot be demonstrated. This is the column that separates a control from an intention, and it is the one most often missing.

“What happens when it fails?” A control that fails open is not a control. This question also surfaces the cases where a policy was written as a hard requirement and implemented as a preference, which is a common and entirely understandable drift once somebody meets the population it would have excluded.

Applying those four questions to an existing matrix typically reclassifies a handful of rows from preventive to compensating, removes one or two that turn out to be unenforceable, and adds a column of evidence queries that did not previously exist. That is a better outcome than a matrix everybody signs and nobody can substantiate.

What Changes for an Assessor

An assessor arriving at a passkey deployment is usually working from a mental model built on passwords and one-time codes, and three things will be unfamiliar enough to need explaining before the control discussion can be productive.

There is no shared secret to protect. The credential table holds public keys, and a breach of it is a privacy event rather than an authentication one. Assessors accustomed to asking about hashing algorithms, salt handling and password rotation will find none of those questions apply, and the honest framing is that the entire category of control has been removed rather than satisfied. What replaces it is a question about the linkage between people and devices, which is a data-protection concern with different owners and different retention rules.

The strongest control is enforced by something you do not own. Origin binding happens in the browser, before any of your code runs. That is unusual in a control matrix, where most rows point at something the organisation implemented, and it is worth stating explicitly: this control does not depend on your code quality, your deployment hygiene or your test coverage, which is precisely why it is the strongest thing in the list.

Some familiar controls have become unavailable rather than unnecessary. Clone detection through the signature counter is the clearest example: it was a real control for hardware tokens and it does not fire for synced credentials. Presenting that as a gap, with the compensating properties named — non-exportable keys, per-origin credentials, platform account security — is more credible than presenting it as a control that is still in place.

Preparing those three explanations in advance, with the evidence queries attached, converts what is often a multi-week back-and-forth into a single session. It also tends to surface the one or two rows in your own matrix that were inherited rather than reasoned about, which is worth finding before somebody else does.

Related