Every MFA programme collects exemptions, and the ones nobody wrote down are the ones attackers find first. A user group excluded from a Conditional Access policy during a device refresh, a shared mailbox kept on legacy authentication, a service account excluded "temporarily" three years ago: each is a sign-in path with a single factor. This template gives [Organisation] a ready-to-use procedure and register for MFA exceptions: which exceptions are allowed, who approves them, which compensating controls apply, when they expire and how they are reviewed. It is for identity and access management teams, security operations and internal audit. The rules for MFA itself sit in the Authentication and MFA Policy Template; this page covers only the exceptions to it.
How to use this template
- Adopt it as the only route to an MFA exemption. Any account excluded from an MFA requirement, in any identity provider or application, must have a register entry. An exclusion with no entry is an incident, not an exception.
- Replace the bracketed values ([Organisation], approver titles, maximum durations, review cadences) and get them approved by the owner of the authentication policy. Durations shown are NHI Mgmt Group recommendations, not values from a standard.
- Keep the register where the exclusions live. Hold it in your GRC or ticketing tool, and mirror each entry with a named exclusion group in the identity provider so the register and the technical configuration can be reconciled automatically.
- Find the exclusions you already have first. Before go-live, inventory every current exclusion and backfill entries. See How to Find Accounts Excluded From MFA and Conditional Access.
- Use the general exception process for everything else. Non-MFA deviations follow [Organisation]'s security exception procedure. See the Security Exceptions and Risk Acceptance Guide.
1. Purpose and scope
1.1 This procedure controls every exception to [Organisation]'s requirement for multi-factor authentication, so that each exemption is justified, approved, time-limited, protected by compensating controls and reviewed.
1.2 It applies to all human accounts (staff, contractors, guests, partners and administrators) and to every system that enforces or should enforce MFA: the primary identity provider, Conditional Access or sign-on policies, VPN and remote access, cloud consoles, SaaS applications with local sign-in, and privileged access tools.
1.3 An MFA exception exists when an account (a) is excluded from an MFA policy, (b) can sign in through a protocol or path that bypasses MFA (for example legacy authentication), (c) is allowed a weaker method than the policy requires (for example SMS where phishing-resistant MFA is required), or (d) is in scope of a "trusted location" or "trusted device" rule that skips MFA.
1.4 Workload identities (service accounts, API keys, OAuth clients, automation accounts) cannot perform interactive MFA. They are out of scope of this register and are governed under [Organisation]'s non-human identity standard, which requires them to authenticate with short-lived credentials, workload federation or certificates instead. A human account used as a service account is in scope and must be converted or registered here. See the NHI Authentication Guide.
2. Roles
| Role | Responsibility |
|---|---|
| Requester | Raises the request, states the business reason and accepts the compensating controls. Usually the account holder's manager or the system owner. |
| Exception owner | Named person accountable for the exception until it closes. Must be a [Organisation] employee, never a group mailbox or a supplier. |
| Identity team | Assesses the request, implements the exclusion through the named exclusion group only, applies compensating controls and removes the exclusion at expiry. |
| Approver | Approves according to the authority table in section 4. Must not be the requester or the exception owner. |
| Security operations | Monitors excluded accounts as set out in section 6. |
| Internal audit | Samples the register against the identity provider configuration each [quarter]. |
3. Permitted exception categories
3.1 Only the categories below may be registered. Anything else is refused or escalated to the [CISO] as a risk acceptance.
| Category | Typical case | Maximum duration (our recommendation) | Required compensating controls |
|---|---|---|---|
| A. Emergency access (break glass) | Two or more cloud-only administrator accounts excluded from blocking policies so the tenant can be recovered | Standing, revalidated every [90] days | Phishing-resistant method that is not tied to one person, credentials in separate safes, alert on every sign-in, regular sign-in tests |
| B. Temporary enrolment gap | New starter or replacement device not yet registered; lost or broken authenticator | [7] days | Temporary access pass or supervised re-enrolment, sign-in limited to managed devices or named locations |
| C. Device or location constraint | Users on unsupported devices during a replacement programme; site with no mobile coverage | [90] days | Alternative method (hardware security key), compliant device requirement where possible, location restriction |
| D. Legacy protocol or application | Application or mail client that cannot perform modern authentication | [180] days, with a funded remediation plan | Restrict to the specific resource and source network, strong unique password, sign-in risk monitoring, decommission date |
| E. Weaker method allowed | User cannot use the required phishing-resistant method (for example an accessibility need or no smartphone) | [365] days, reviewed with the user | Strongest method the user can use, recovery through verified process only, higher monitoring |
| F. Supplier or partner constraint | Guest users whose home organisation cannot meet the MFA requirement | [90] days, renewable once | Access limited to named applications, access review by the business owner, contract action to fix |
3.2 Microsoft lists similar real-world reasons for Conditional Access exclusions, including users on unsupported devices, travellers outside allowed regions and users who still need legacy authentication, and recommends managing each through a security group reviewed with access reviews. Treat the categories above as the [Organisation] equivalent for every identity provider in use.
3.3 Exceptions are never granted for: privileged roles other than category A; accounts with access to [production cloud consoles, finance approval systems or customer data exports]; or any account where the reason is convenience alone.
4. Request and approval
4.1 The requester submits the request form (section 8) before the exclusion is made, except for category B during an urgent outage, where the identity team may act first and the request must follow within [1] working day.
4.2 Approval authority:
| Exception | Approver |
|---|---|
| Category B, single user, up to [7] days | Identity team lead |
| Categories C, E and F | [Head of IAM] and the business owner of the affected applications |
| Category D, or any exception covering more than [25] accounts | [CISO] |
| Category A (new accounts or a change of method) | [CISO] and [CIO] |
| Any renewal past the maximum duration | [Risk committee] |
4.3 The identity team implements the exception by adding the account to a dedicated, assigned (not dynamic) exclusion group named after the category and register ID, for example MFAEX-D-0042-LegacyPayroll. Policies exclude groups, never individual users, so that every exclusion is visible and countable.
5. Compensating controls
5.1 Each exception must carry the controls listed for its category in section 3, verified by the identity team before the exclusion takes effect and recorded with evidence (policy name, screenshot or configuration export).
5.2 Where the exemption is from a specific method rather than MFA altogether, give the user the strongest alternative available. NIST SP 800-63B-4 treats SMS and voice one-time codes as a restricted authenticator: verifiers must make alternative authenticator types available and should check risk signals such as SIM change or number porting before relying on the phone network.
5.3 For emergency access accounts follow the Break Glass Access Procedure Template. Microsoft's current guidance is at least two cloud-only accounts, excluded through a dedicated group, using passkeys (FIDO2) or certificate-based authentication, with an alert on any sign-in and validation at least every 90 days.
6. Monitoring
6.1 Security operations must alert on: any sign-in by a category A account; sign-in by an excluded account from outside its permitted location or device scope; any change to an exclusion group's membership that has no matching register entry; and any new exclusion added to an MFA policy.
6.2 Excluded accounts are tagged as high risk in the SIEM, with sign-in risk detections reviewed within [4] hours.
6.3 Attempts to register a new MFA method on an excluded account during the exception are investigated. See How to Detect MFA Method Registration Abuse.
7. Expiry, review and closure
7.1 Every entry has an expiry date. The identity team sends reminders [14] and [3] days before expiry. At expiry the account is removed from the exclusion group automatically unless an approved renewal is on file.
7.2 Renewal requires a fresh request with progress against the remediation plan. A copied request is refused.
7.3 Exclusion groups are reviewed [monthly] for categories B, C and F and [quarterly] for D and E. Reviewers are the business owners, with non-response removing the user. Where the identity provider supports recurring access reviews with auto-apply, use them, and keep their results as audit evidence.
7.4 Closure is recorded with the date removed and evidence that the account now meets the MFA requirement (for example a successful sign-in with the required method).
8. Register fields and request form
8.1 Each register entry holds the following fields. The request form collects the first eleven.
| # | Field | Example |
|---|---|---|
| 1 | Register ID | MFAEX-0042 |
| 2 | Category (A to F) | D |
| 3 | Accounts covered (UPN or ID, count) | payroll-sync@[domain] and 3 users |
| 4 | Systems and policies affected | "Require MFA for all users" policy; payroll SFTP gateway |
| 5 | Exemption type | Excluded from policy / legacy protocol / weaker method / trusted location |
| 6 | Business reason | Payroll application supports basic authentication only until v12 upgrade |
| 7 | Risk if exploited | Password spray could expose payroll data for [n] staff |
| 8 | Compensating controls | Named location restriction, sign-in risk alert, 20-character unique password |
| 9 | Remediation plan and target date | Upgrade funded, target [date] |
| 10 | Requester and exception owner | [Name], [Name] |
| 11 | Requested expiry | [date] |
| 12 | Approver and approval date | [CISO], [date] |
| 13 | Exclusion group name | MFAEX-D-0042-LegacyPayroll |
| 14 | Controls verified (by, date, evidence link) | [Name], [date], [link] |
| 15 | Last review and outcome | [date], retained |
| 16 | Renewal count | 0 |
| 17 | Status and closure date | Open / Expired / Closed |
9. Reporting
9.1 The identity team reports to [the security steering group] each month: open exceptions by category; accounts excluded as a share of all accounts in MFA scope; exceptions past expiry; exceptions renewed more than once; median age of open exceptions; and unregistered exclusions found by reconciliation.
9.2 Targets set by [Organisation]: zero unregistered exclusions, zero expired exceptions still active, and a falling count of category D and E exceptions each quarter.
Implementation guidance
- Inventory first. Export every MFA or sign-on policy and list its exclusions, including users excluded directly, trusted locations and protocols that bypass MFA. Expect to find exclusions nobody can explain.
- Backfill and assign owners. Create a register entry for each, give it an owner and a 30-day expiry, and let the owner either justify it under section 3 or let it lapse.
- Move to group-based exclusions. Replace direct user exclusions with the named groups in section 4.3. Test with report-only or audit mode policies before changing enforcement, and keep emergency access accounts excluded throughout so you cannot lock yourself out.
- Automate reconciliation. Compare exclusion group membership with the register daily and raise a ticket for any difference.
- Roll back safely. If removing an exclusion breaks a business process, restore the account to the group under a category B entry for no more than [7] days while the fix is found, rather than disabling the policy.
- Map for audit. NIST SP 800-53 Rev. 5 IA-2 Identification and Authentication (Organizational Users) and AC-2 Account Management; NIST CSF 2.0 PR.AA-03 (users, services and hardware are authenticated) and ID.RA-07 (changes and exceptions are managed, assessed for risk impact, recorded and tracked); RA-7 Risk Response for formal acceptances.
Common failure patterns to avoid: excluding individual users directly in a policy so nobody can count them; "temporary" exclusions with no expiry; trusted network locations so broad they cover most sign-ins; break-glass accounts registered to one administrator's phone; and service accounts that are really shared human logins, kept in the register forever instead of being converted to workload identities.
Related NHI Mgmt Group resources: MFA Guide · Conditional Access Guide · Phishing-Resistant MFA Guide · Break-Glass Account Guide · Top 10 MFA Mistakes