Customer Authentication Policy Template: Passkeys, MFA, Risk Signals and Recovery

Most customer account takeover does not beat the strongest sign-in method a service offers, it walks around it through a weaker fallback, an SMS code, a recovery email or a call centre reset. A written customer authentication policy is how product, fraud, security and support teams agree which methods are allowed, when extra checks fire and how a locked-out customer gets back in without opening a side door. This template is for organisations that run consumer or business customer accounts: retailers, banks, fintechs, SaaS providers and public services. It covers authenticator tiers, passkey adoption, step-up rules driven by risk signals, session limits, recovery and notifications, and maps the controls to NIST SP 800-63B-4 and OWASP ASVS 5.0. It is the customer counterpart of the Authentication and MFA Policy Template, which covers the workforce.

How to use this template

• Replace text in square brackets, such as [Organisation], [Fraud Operations] and [Customer Support], with your own names, and set every value shown as [X] to suit your risk appetite and customer base.
• "Must" is mandatory; "should" is recommended, and any deviation needs a recorded reason and an owner.
• Values given in brackets with a suggested number, such as [1 hour], are NHI Mgmt Group suggestions drawn from NIST SP 800-63B-4 where noted. They are starting points, not regulatory minimums.
• If you are a payment service provider in the EEA or UK, strong customer authentication rules apply on top of this policy. Check them against the PSD2/PSD3 Strong Customer Authentication Guide and your regulator's current text.
• List only methods your platform can actually deliver. An unsupported method in the policy becomes an exception on day one.
• Review the policy at least annually, after any account takeover incident and before launching a new sign-in channel such as a mobile app or voice assistant.

1. Purpose

This policy sets the minimum standard for how [Organisation] authenticates its customers, protects their sessions, and restores access when a customer cannot sign in. Its aims are to prevent account takeover and fraud, to keep sign-in usable for every customer group, including people without smartphones, and to meet the legal and contractual obligations that apply to customer accounts.

2. Scope

• In scope: every customer-facing sign-in channel run by or for [Organisation], including websites, mobile apps, APIs used by customer apps, contact centre and chat authentication, in-store or branch identification for account changes, and federated sign-in (social login or enterprise single sign-on into customer tenants).
• Customer types: individual consumers, business customer administrators and users, and delegated users acting for a customer (carers, family members, accountants). See the Delegated and Proxy Access CIAM Guide.
• Out of scope: workforce authentication, which is covered by [Workforce Authentication Policy], and machine access to partner APIs, which is covered by [API Security Policy]. Initial identity proofing at onboarding is covered by [Identity Verification Standard] and referenced here only where recovery depends on it.

3. Roles and responsibilities

4. Authenticator tiers

[Organisation] classifies customer authenticators into tiers. Tiers drive which actions a session may perform (section 6).

• 4.1 Prohibited methods: security questions and other knowledge-based answers must not be used to sign in or recover an account. Email must not be used as an authentication factor for any action above Tier D.
• 4.2 Passwords: where passwords remain, they must be at least [15] characters when used alone and at least [8] characters when used with a second factor, must accept at least 64 characters and password managers, must be checked against a list of common and breached passwords, and must not be subject to composition rules or forced periodic change. These values follow NIST SP 800-63B-4.
• 4.3 SMS and voice codes: must only be sent to a number validated at enrolment, must expire within [10 minutes], must be bound to the transaction that requested them, and must be preceded by a check for a recent SIM change or port where the data is available. See the OTP security guide.
• 4.4 Push approvals: must use number matching or show the transaction details, and must be rate limited to prevent push fatigue.

5. Passkey adoption

• 5.1 Offer: [Organisation] must offer passkey enrolment to every customer on supported platforms by [date], and should prompt enrolment after a successful sign-in rather than at registration only.
• 5.2 Synced and device-bound: synced passkeys are accepted for all customer actions up to and including payments and account changes. Customers or segments that need the highest assurance, for example high-value business administrators, should be offered device-bound security keys.
• 5.3 Multiple authenticators: customers must be encouraged to register at least two authenticators, for example a passkey on a phone and a second passkey or security key, so that losing one device does not force a recovery.
• 5.4 Password removal: once a customer has two Tier A authenticators, [Organisation] should let the customer remove their password. Removing it closes the phishable fallback.
• 5.5 New devices: sign-in from a new device using cross-device authentication (QR code and proximity) is treated as a normal Tier A sign-in. Sign-in from a new device by any other means is treated as a recovery event under section 9.

See the Passkey Rollout Guide for rollout sequencing and the Passkey account recovery guide for loss scenarios.

6. Step-up and risk signals

[Organisation] uses risk signals to decide when to ask for more proof. Risk scoring adds friction, it never removes a required tier.

• 6.1 Signals: [Fraud Operations] may use device reputation and binding, IP reputation and anonymiser detection, geolocation and impossible travel, velocity across accounts, bot detection, SIM-swap data, breached-credential matches and behavioural patterns. The list in use must be documented and covered by the privacy risk assessment.
• 6.2 Outcomes: each score band maps to an outcome: allow, step up, hold for review, or block. Outcomes and thresholds are recorded in [Risk Rules Register] with an owner and last review date.
• 6.3 Attack conditions: during a declared credential stuffing attack, [Security Operations] may raise thresholds for all customers for up to [72 hours] without a policy exception. See the Credential Stuffing Attack Response Playbook.
• 6.4 Fairness: rules must not rely on a single signal that disproportionately blocks a customer group, such as a country or a device age, without a review by [Fraud Operations] and [Privacy Officer].

See the Risk-Based and Adaptive Authentication Guide for signal design.

7. Sessions

• 7.1 Timeouts: sessions that can make payments or account changes must time out after [1 hour] of inactivity and [24 hours] overall, in line with the NIST SP 800-63B-4 AAL2 limits. Read-only sessions in a trusted app may last up to [30 days].
• 7.2 Cookies and tokens: session cookies must be Secure, HttpOnly and narrowly scoped, and must contain no cleartext personal data. Mobile refresh tokens must be stored in the platform keystore.
• 7.3 Remember this device: a remembered device may skip the second factor at sign-in but must never skip the step-up rules in section 6.
• 7.4 Termination: after a password, email, phone or authenticator change, all other sessions and refresh tokens for the account must be revoked. Customers must be able to see and end active sessions.
• 7.5 Token theft: [Product and Engineering] should adopt device-bound session credentials or token binding where the platform supports them. See the Device-Bound Session Credentials (DBSC) Guide.

8. Rate limiting and enumeration

• 8.1 Limits: failed attempts must be limited per account and per source, with a hard ceiling of [10] consecutive failures per account before a cooling-off period. NIST SP 800-63B-4 sets an upper bound of 100; consumer services usually need a much lower number paired with bot defence.
• 8.2 Enumeration: sign-in, registration and forgotten-password responses must not reveal whether an account exists, through wording, status codes or timing.
• 8.3 Automation: bot detection must protect sign-in, registration, recovery and one-time-code endpoints. See the Bot Management Guide.

9. Account recovery

Recovery must be at least as strong as the sign-in it replaces. A recovery path weaker than sign-in sets the real strength of the account.

1. Self-service first: customers recover with a remaining registered authenticator, a saved recovery code issued at enrolment (single use, stored hashed), or a recovery contact they nominated.
2. Two pieces of evidence: where no authenticator remains, recovery of a multi-factor account must require two independent pieces of evidence, for example an issued code to a verified phone plus an issued code to a verified email, or repeated identity proofing to the level used at onboarding.
3. Code lifetimes: issued recovery codes expire within [10 minutes] for SMS or voice and [24 hours] for email.
4. Cooling-off: after recovery, high-risk actions in section 6 (new payees, contact detail changes) are held for [24 to 72 hours] unless the customer re-verifies through repeated identity proofing.
5. Assisted recovery: [Customer Support] must follow [Assisted Recovery Procedure]. Agents must not change contact details and reset authenticators in the same interaction, must not accept information available from public sources or a data breach as proof, and must escalate any customer who pushes for an exception. See the Account Recovery and Help Desk Security Guide.
6. Business customers: recovery for a business administrator must be approved by a second administrator of the same customer where one exists.

10. Notifications

• 10.1 Events: customers must be notified of new authenticator enrolment, password or contact detail changes, recovery, sign-in from a new device, and suspicious failed attempts.
• 10.2 Channels: notifications must go to every registered contact channel, and changes to a contact detail must be notified to the old detail as well as the new one.
• 10.3 Content: each notification must say what happened, when, and how to report it if the customer did not do it, with a link or number that does not depend on the possibly compromised session.

11. Logging and monitoring

• 11.1 Events: log every sign-in, step-up, failure, authenticator change, recovery, session revocation and risk decision with the account, device, source, outcome and rule that fired.
• 11.2 Retention and access: keep authentication logs for [X months], protected from alteration, with access limited to [Security Operations] and [Fraud Operations].
• 11.3 Review: [Fraud Operations] reviews confirmed takeover cases monthly to find which pathway was used and feeds the result into section 6 rules.

12. Exceptions

Exceptions must be requested in writing, state the pathway and customer group affected, the compensating control and an expiry date no longer than [6 months], and be approved by [Policy Owner]. Accessibility exceptions for individual customers are handled by [Customer Support] under [Accessibility Procedure] and do not need policy-owner approval, but must still meet section 9.

13. Review and approval

Policy owner: [Name, role]. Approved by: [Committee]. Effective date: [date]. Next review: [date]. Version: [1.0].

Implementation guidance

1. Inventory every pathway. List each way a customer can get into an account or change it: web, app, API, chat, phone, store, social login, recovery. Undocumented pathways are where attackers go. OWASP ASVS 5.0 requirements V6.1.3 and V6.3.4 ask for exactly this.
2. Measure the current fallback. Find out what share of sign-ins and recoveries use SMS, email links or support calls today. That is your real assurance level.
3. Remove knowledge-based answers first. They are the cheapest gap to close (ASVS V6.4.2) and usually the most abused in assisted recovery.
4. Launch passkeys alongside passwords. Prompt after sign-in, track enrolment by platform, then encourage a second authenticator and password removal.
5. Turn on step-up rules in monitor mode. Log the outcome each rule would have produced for two to four weeks, check false positives by customer group, then enforce. Roll back by switching a rule to monitor, not by deleting it.
6. Harden recovery last but thoroughly. Add cooling-off holds and two-evidence recovery once passkey adoption reduces recovery volume, so support queues do not spike.

Control mapping

Metrics to track: share of active customers with a passkey; share of sign-ins completed at Tier A; share of recoveries completed through support rather than self-service; confirmed account takeovers per 10,000 active accounts, split by pathway; step-up challenge rate and abandonment rate by customer group; median time from takeover to customer notification.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management
• OWASP: Application Security Verification Standard 5.0
• FIDO Alliance: Passkeys
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Passwordless and Passkeys Guide · Risk-Based and Adaptive Authentication Guide · Account Takeover Prevention Guide