You're ready to deploy passkeys. You've read the NIST SP 800-63-4 guidance, you understand WebAuthn domain-binding, and your executive sponsor wants phishing-resistant authentication live by Q2. Now you need a policy that governs how customers register, recover, and use passkey credentials without creating new attack surfaces.
This template provides a policy framework addressing enrollment controls, recovery procedures, and fraud monitoring. It's designed for banks because the stakes are higher, you're not just authenticating users, you're authorizing payments and protecting regulated accounts.
Purpose of the Template
This enrollment policy template defines the rules and procedures for passkey lifecycle management in a banking environment. It covers:
- Customer enrollment requirements and verification steps
- Device attestation and credential storage rules
- Account recovery procedures for lost passkeys
- Fraud detection triggers during enrollment and authentication
- Evidence collection for audit and compliance reporting
The template assumes you're implementing WebAuthn Level 3 credentials and need to meet both NIST's authenticator assurance requirements and your internal fraud controls. It's not a button-level feature spec, it's the control plane policy above your authentication service.
Prerequisites
Before customizing this template, ensure you have:
- A WebAuthn-compatible relying party implementation that can request and verify attestation
- Integration with your fraud detection system to flag suspicious enrollment patterns
- A customer identity proofing process that meets NIST Identity Assurance Level 2 or higher
- Defined roles for customer support, fraud operations, and security incident response
- A credential recovery path that avoids phishing risk (no SMS fallback for high-value actions)
If you're still using manually entered One-Time Passwords as your primary second factor, phase them out for payment approval and account changes. NIST states that manually entered OTP authenticators are not phishing-resistant because a user can be tricked into entering an OTP on a fake site.
The Template
PASSKEY ENROLLMENT AND LIFECYCLE POLICY
Version 1.0
1. [SCOPE](/glossary/scope)
This policy applies to all customer-facing authentication flows where
passkeys are offered or required, including account login, payment
authorization, profile changes, and account recovery.
2. ENROLLMENT REQUIREMENTS
2.1 Eligibility
- Customer must have completed identity proofing to IAL2 or equivalent
- Customer must authenticate with existing credential before enrolling
first passkey
- Customer device must support WebAuthn (browser or native client)
2.2 Attestation
- Request attestation during enrollment to verify authenticator type
- Log attestation format (packed, android-safetynet, apple, etc.)
- Flag non-platform authenticators for additional fraud review if
enrollment occurs outside normal customer pattern
2.3 Enrollment Limits
- Maximum [3] passkeys per customer account
- Maximum [2] enrollments per 24-hour period per account
- Temporary suspension after [5] failed enrollment attempts
2.4 Verification Steps
- Customer must re-authenticate with existing credential
- Customer must confirm enrollment via out-of-band channel
(push notification to registered device or email to verified address)
- Log enrollment timestamp, device type, IP address, user agent
3. CREDENTIAL STORAGE AND BINDING
3.1 Relying Party Requirements
- Store only public keys; never store private key material
- Bind credential to relying party identifier (your domain)
- Associate credential with customer account ID and device metadata
- Record credential creation date and last use timestamp
3.2 Syncable Authenticator Handling
- Accept syncable passkeys (iCloud Keychain, Google [Password Manager](/glossary/password-manager))
per NIST SP 800-63-4
- Require re-authentication on new device even if passkey syncs
- Monitor for passkey use from unexpected geographic locations
4. AUTHENTICATION REQUIREMENTS
4.1 Challenge Protocol
- Generate fresh challenge for each authentication attempt
- Enforce challenge timeout of [2 minutes]
- Verify signature against stored public key
- Check that relying party ID matches expected value
4.2 User Verification
- Require user verification (biometric or device PIN) for all
authentication attempts
- Do not accept user presence alone for payment or account changes
- Log verification method used (fingerprint, face, PIN)
5. ACCOUNT RECOVERY
5.1 Passkey Loss or Device Change
- Customer must authenticate via recovery credential (hardware security
key registered during enrollment, or knowledge-based verification
reviewed by fraud team)
- Do NOT offer SMS OTP as recovery path for payment approval
- Require identity re-proofing if all credentials are lost and no
recovery credential exists
5.2 Recovery Credential Registration
- Prompt customer to register recovery credential during initial
passkey enrollment
- Recovery credential must be phishing-resistant ([FIDO2](/glossary/fido2) security key
or device-bound passkey on separate device)
- Customer support cannot bypass recovery process without fraud
operations approval
6. FRAUD DETECTION AND MONITORING
6.1 Enrollment Monitoring
- Flag enrollment from new device type if customer has existing passkey
- Flag enrollment immediately following password reset
- Flag multiple enrollment attempts from same IP across different
accounts
- Require step-up verification if fraud score exceeds threshold
6.2 Authentication Monitoring
- Flag authentication from new geographic region without travel
notification
- Flag authentication immediately following device change
- Flag rapid authentication attempts across multiple accounts
- Correlate passkey use with transaction risk score
6.3 Evidence Collection
- Log enrollment and authentication events to SIEM
- Retain attestation data and device metadata for [90 days]
- Provide audit trail for compliance reporting
- Generate alert if passkey is used for payment after account
takeover indicators
7. CUSTOMER COMMUNICATION
7.1 Enrollment Notification
- Notify customer via email and push notification when passkey is
enrolled
- Include device type and enrollment timestamp
- Provide link to view and revoke credentials
7.2 Authentication Notification
- Notify customer of first authentication from new device
- Notify customer if passkey is used for high-value transaction
- Provide immediate revocation option in notification
8. SUPPORT AND INCIDENT RESPONSE
8.1 Customer Support Procedures
- Support cannot enroll passkey on behalf of customer
- Support can revoke compromised credential after identity verification
- Support must escalate to fraud operations if customer reports
unauthorized enrollment
8.2 Incident Response
- Revoke all passkeys if account takeover is confirmed
- Require identity re-proofing before new enrollment
- Notify customer of revocation and next steps
- Log incident and credential revocation in audit trail
9. POLICY REVIEW
This policy will be reviewed [quarterly] and updated based on:
- NIST guidance updates
- Fraud pattern analysis
- Customer support escalation trends
- Regulatory examination findings
Customization Tips
Adjust enrollment limits based on your fraud data. If you notice credential stuffing attacks, tighten the enrollment rate limit. For high-value customers who travel frequently, allow more passkeys per account but require attestation review.
Define your attestation policy based on risk tolerance. Decide whether to accept any WebAuthn authenticator or require platform authenticators for payment approval while accepting syncable authenticators for login.
Specify your recovery path based on customer demographics. For tech-savvy customers, require a FIDO2 security key as the recovery credential. For a broader retail base, allow knowledge-based verification reviewed by your fraud team, but never use SMS OTP for payment approval.
Set fraud thresholds that match your existing transaction monitoring. The template flags enrollment after password reset because it's a common account takeover pattern. Add indicators like enrollment from VPN, outside business hours, or from unknown devices.
Integrate with your SIEM by defining which events generate alerts. Log enrollment, authentication, recovery, and revocation. Send high-severity alerts for enrollment after password reset, authentication from a new country, or passkey use for payment after a fraud score spike.
Validation Steps
Before rolling out this policy, validate each control:
Test enrollment flow with attestation enabled. Confirm your relying party can parse attestation statements and log authenticator type.
Simulate account takeover by enrolling a passkey after password reset. Verify your fraud system flags the enrollment and requires step-up verification.
Test recovery procedure by revoking all passkeys and attempting account recovery. Confirm SMS OTP is not offered as a recovery path for payment approval.
Review SIEM integration by enrolling and authenticating with a passkey, then querying your SIEM for logged events. Confirm you can generate an audit trail for compliance reporting.
Run tabletop exercise with customer support and fraud operations. Walk through a scenario where a customer reports unauthorized passkey enrollment. Confirm support knows to escalate and fraud operations knows to revoke credentials.
Check compliance mapping by reviewing NIST SP 800-63-4 Section 5.1.7 (syncable authenticators) and confirming your policy addresses verifier requirements for public key storage, challenge protocol, and user verification.
This policy is your starting point, not your finish line. As you gather enrollment and fraud data, refine thresholds, add indicators, and adjust recovery procedures. Aim for a control plane that provides evidence, not just a button that says "Sign in with passkey."
