On this page
A passkey deployment depends on more than credential registration. Trust metadata can become unavailable, an authenticator can acquire a compromise status, and a login-domain change can invalidate the assumptions behind existing credentials.
ProAuth 3.2.0 adds operational controls for those cases, including FIDO metadata trust, credential investigation and DNS-verified relying-party ID migration. They are particularly relevant when passwordless policy depends on attestation and credential diversity.
Treat metadata as a shared operational dependency
ProAuth maintains a verified, versioned last-known-good FIDO metadata snapshot. Failed refreshes retain an installed valid snapshot. That preserves continuity, while still leaving operators responsible for investigating freshness and the reported failure.
The global trust view exposes snapshot state, timestamps, entry count and refresh errors. Signed offline import provides a controlled path where normal online retrieval is unavailable; signature and freshness validation still apply. A pasted unsigned catalog is not a trusted replacement.
The passkey security operations guide documents trust behavior. If policy requires metadata and no usable snapshot exists, new registration or trust establishment is blocked. Retaining a snapshot does not mean ignoring a mandatory authenticator compromise status.
Coordinate the compact-cache transition
Version 3.2 omits embedded authenticator artwork and compresses the protected snapshot, reducing state-store traffic while preserving trust information and evidence fingerprints. Older binaries cannot read the compact format.
Upgrade nodes sharing the state store together and preserve the shared Data Protection keys. If larger transport limits were configured for the old snapshot, retain them until the compact snapshot has been saved and successfully reloaded. The release notes describe this compatibility requirement.
Investigate a credential using evidence
A friendly credential name is insufficient to identify the authenticator involved in an incident. Review lifecycle, relying-party binding, last use and available trust evidence. Distinguish a confirmed compromise from a temporary policy hold or provider outage.
Revoking a credential as compromised is permanent and can require recovery if no usable credential remains. Conversely, preserving a compromised credential merely to avoid a support case leaves the original problem unresolved. Verify the user’s remaining access and recovery path after the response.
Move the RP ID through an explicit migration
WebAuthn credentials are scoped to their RP ID. Editing that ID cannot turn an old credential into one for a new domain. ProAuth blocks a direct RP ID change while active credentials exist and provides a dual-RP migration workflow.
flowchart TD
Start[Start old and new RP migration] --> DNS[Publish and verify both DNS challenges]
DNS --> Overlap[Use bounded verified overlap]
Overlap --> Enroll[Enroll credentials for the new primary RP]
Enroll --> Review[Review users still relying on the old RP]
Review --> Retire[Approve and retire the legacy RP]Every credential retains its exact RP binding. The overlap gives users time to enroll new credentials; it does not rewrite the old ones. Retirement can force remaining users into recovery, so review that consequence and obtain any required independent approval.
Before a domain project starts, inventory active credentials, set an overlap period and rehearse recovery for users who miss it. Use the administration views guide for the migration workspace. A domain rename is an authentication lifecycle change, and its plan should include both the successful enrollment and the user who does not return in time.