Authentication and MFA Policy Template: Setting Phishing Resistant Sign In Requirements

An MFA policy that only says "MFA is required" leaves the gaps attackers use: SMS codes on admin accounts, push prompts approved under fatigue, recovery by a phone call to the help desk, and service accounts that never had a second factor at all. This template gives you an authentication and MFA policy with numbered statements you can adopt as written: which accounts need which strength, when phishing-resistant methods and passkeys are mandatory, session lifetimes, enrolment, recovery, exceptions and how non-human identities authenticate. Assurance levels and timeouts follow NIST SP 800-63B-4, method ranking follows CISA's phishing-resistant MFA guidance, and the policy is mapped to ISO/IEC 27001:2022 and NIST CSF 2.0. It is written for CISOs, IAM leads and GRC teams. Password rules sit in the companion Password Policy Template; this policy covers everything else about how identities prove who they are.

How to use this template

• Replace text in square brackets, such as [Organisation], [identity provider] and [X hours], with your own terms and values. Values in brackets are illustrative starting points; where a value comes from NIST SP 800-63B-4 the policy says so.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply under section 5.
• Keep product configuration (conditional access rules, authentication strength policies, identity provider settings) in a supporting authentication standard. See the Conditional Access Guide for how these statements become enforceable rules.
• The method tiers in 4.2 are the heart of the policy. Adjust which tier each population needs, but do not merge tiers: the distinction between phishing-resistant and other MFA is what stops modern attacks.

1. Purpose

This policy sets the requirements for how users, administrators, customers where applicable, and non-human identities authenticate to [Organisation] systems, so that authentication strength matches the risk of what is being accessed, phishing-resistant methods protect high-value access, sessions do not outlive their purpose, and lost authenticators are recovered without creating a weaker path around them.

2. Scope

This policy applies to all authentication to [Organisation] systems, applications, cloud tenants, SaaS services, networks and devices, by:

• Workforce users: employees, contractors and temporary staff.
• Privileged users: anyone holding administrative roles, including in identity providers, cloud management consoles, security tools and production systems.
• Third parties: suppliers and partners with accounts in [Organisation] systems.
• Non-human identities: service accounts, workload identities, API clients, CI/CD pipelines and AI agents.
• [Customers, if in scope]: users of [Organisation] customer-facing services.

3. Roles and responsibilities

4. Policy statements

4.1 General requirements

1. All workforce and third-party access to [Organisation] systems must authenticate through [identity provider] using single sign-on wherever the system supports it.
2. Multi-factor authentication must be required for all workforce and third-party interactive access, from all networks. Being on the corporate network must not exempt a sign-in from MFA.
3. Legacy authentication protocols that cannot perform MFA (for example basic authentication to mail protocols) must be blocked.
4. Every authentication, success and failure, must be logged with user, method, application, device and source, and retained for at least [12 months].

4.2 Authentication method tiers

[Organisation] recognises three tiers of authentication method. Methods not listed are prohibited unless approved under section 5.

4.3 Required strength by access type

1. Sensitive actions (changing authentication methods, approving payments above [amount], elevating privilege, exporting bulk data) must require fresh authentication at the tier above, regardless of session age.
2. Sessions must be revoked on password reset, authenticator removal, account disablement and confirmed compromise, including refresh tokens and persistent sessions.
3. Devices used for Tier 1 privileged access should be managed and compliant; [identity provider] should require device compliance for privileged roles.

4.4 Passkeys and phishing-resistant rollout

1. [Organisation] must offer at least one Tier 1 or Tier 1s method to every workforce user. (NIST SP 800-63B-4 requires verifiers at AAL2 to offer a phishing-resistant option.)
2. Rollout must prioritise, in order: identity and cloud administrators, service desk staff, executives and their assistants, finance and HR, then all users. This follows CISA's advice to start with high-value targets and IT staff.
3. Once a user has enrolled a Tier 1 or 1s method, weaker methods should be removed from that user's account so attackers cannot downgrade to them.
4. Every user should register at least two authenticators, for example a passkey on a phone and a security key, so that loss of one does not force recovery.

4.5 Enrolment

1. New users must enrol MFA before receiving access to any data, using a time-limited onboarding credential (for example a temporary access pass valid for no more than [8] hours) issued after identity verification.
2. Enrolment of the first authenticator must take place from a managed device or a trusted location, or be verified by [Service desk] or the line manager.
3. Adding or changing an authenticator must require authentication with an existing authenticator of equal or higher tier, and must notify the user through a separate channel.
4. [Organisation] must keep a record of all authenticators bound to each account, with date and time of binding and removal.

4.6 Recovery

1. Users should recover by using their second registered authenticator. Self-service recovery must never be weaker than the tier the account requires.
2. Where service desk recovery is needed, identity must be verified under the [Help Desk Identity Verification Policy]: for example video verification against an identity document, manager confirmation through a known channel, or in-person checks. Knowledge-based questions and caller ID alone must not be accepted.
3. Recovery of privileged accounts must require approval from a second person in [Identity team] and must be logged and reviewed.
4. After any recovery, the user must be notified through an independent channel, all sessions must be revoked, and [Security operations] must be able to see the event.
5. Backup or recovery codes, if issued, must be single use and stored by the user offline or in an approved password manager.

4.7 Emergency (break-glass) accounts

1. No more than [2] break-glass accounts per identity provider or cloud tenant may exist, excluded from conditional access policies only as far as needed to work when the identity provider or MFA service fails.
2. Break-glass accounts must use Tier 1 hardware authenticators or long random credentials held under dual control, and every sign-in must alert [Security operations]. See the Break-Glass Account Guide.

4.8 Non-human identities

1. Non-human identities must not use interactive sign-in and must not be exempted from MFA by being treated as user accounts.
2. Workloads should authenticate with platform-issued, short-lived credentials (workload identity federation, managed identities, mutual TLS certificates or signed client assertions). Static passwords and long-lived secrets are permitted only under an exception with an owner and a rotation interval of no more than [90 days].
3. Service accounts that cannot use MFA must be restricted by network location or device and monitored for interactive use.
4. AI agents must authenticate with their own identity and must not reuse a person's credentials or sessions.

4.9 User conduct

1. Users must not approve an MFA prompt they did not initiate, and must report unexpected prompts to [Security operations].
2. Users must not share authenticators or register an authenticator on another person's device.
3. Lost or stolen authenticators must be reported within [4 hours] of discovery.

5. Exceptions

1. Exceptions must be requested through [GRC tool], stating the requirement, reason, affected accounts, compensating controls (for example network restriction or extra monitoring) and an end date no more than [6 months] away.
2. Exceptions for privileged access must be approved by [CISO]. Exceptions permitting Tier 3 methods for workforce users must also have a migration plan.
3. [Identity team] must keep a register of exceptions and report expired ones as non-compliance.

6. Compliance and monitoring

[Identity team] will report these measures to [Risk committee] [quarterly]:

• Percentage of workforce accounts with MFA enforced (target 100 percent) and with a Tier 1 or 1s method enrolled.
• Percentage of privileged accounts using only Tier 1 methods (target 100 percent).
• Number of sign-ins using Tier 3 methods or legacy protocols, by population.
• MFA prompts denied or reported as unexpected, and number of accounts with repeated prompt bursts.
• Service desk recoveries per month, and recoveries of privileged accounts.
• Non-human identities using static secrets, and open exceptions past their end date.

Non-compliance may lead to access being suspended and to action under [disciplinary or supplier procedures].

7. Review and approval

This policy is reviewed at least annually, after any authentication-related incident and when NIST SP 800-63B or relevant regulation changes, by [CISO]. Version [1.0], approved by [name, role] on [date]. Next review: [date].

Implementation guidance

1. Close the no-MFA gaps first. Before chasing phishing resistance, find every account that can sign in with a password alone, including contractor accounts, legacy protocols and data platforms outside single sign-on. The Snowflake Breach 2024 reached about 165 customer organisations through accounts with no MFA, using passwords harvested by infostealers, some first stolen in 2020.
2. Then move administrators to Tier 1. Issue two security keys or a device-bound passkey plus a key to every administrator, enforce Tier 1 for privileged roles in report-only mode for [two weeks], review the sign-ins that would fail, then enforce.
3. Harden recovery at the same time. Strong MFA is bypassed through the service desk if recovery is weak. Implement 4.6 alongside 4.4; see the Account Recovery and Help Desk Security Guide.
4. Remove weaker methods. Once a population is on Tier 1 or 1s, disable push, OTP and SMS for it, otherwise attackers simply choose the weaker option. See the MFA Fatigue and Bypass Guide.
5. Size to the organisation. A small organisation on one SaaS suite can enforce 4.1 to 4.4 in weeks using built-in security defaults and passkeys. A large enterprise should phase by population, keep a rollback group for each enforcement policy, and track the metrics in section 6 weekly during rollout.
6. Do not forget machines. Section 4.8 is often where attackers go once human MFA is strong. Inventory service accounts that can sign in interactively and move workloads to federated credentials.

Framework mapping

Attacks this policy is designed to stop include MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation (push fatigue), T1111 Multi-Factor Authentication Interception, T1556.006 Multi-Factor Authentication (modifying MFA settings) and T1110.004 Credential Stuffing.

Standards and references

• NIST: SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• NIST: SP 800-63B-4 online text
• CISA: Implementing Phishing-Resistant MFA
• ISO: ISO/IEC 27001:2022 Information security management systems
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: Multi-Factor Authentication Request Generation

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: MFA Guide · Passkey Rollout Guide · NIST SP 800-63B-4 Authenticator Assurance Levels Guide · Help Desk Identity Verification Policy Template · Password Policy Template