AD1.5 Handling MFA Exceptions Without Creating Gaps
Figure AD1.5 — Every MFA exception has a solution that doesn't require exemption from MFA. The right column shows the approved alternative for each common scenario. Document each exception in your exception register with the approved solution, the justification, and a review date.
The executive who refuses MFA
This is the most politically charged exception and the most dangerous to grant. The CFO, CEO, or managing director says MFA is “too inconvenient” and wants to be exempted. Their mailbox contains the organisation’s most sensitive financial and strategic data. It’s the number one target for BEC attackers. Exempting it from MFA is like removing the lock from the bank vault because the bank manager finds keys inconvenient.
The solution is never exemption. It’s a better MFA method. If the executive objects to the phone app, offer a FIDO2 security key. A YubiKey attaches to their keychain or laptop bag and requires a single touch to authenticate — no phone needed, no app to install, no code to type. Total interaction time: under 2 seconds. If they object to any form of second factor, escalate the risk formally: “Exempting this account from MFA increases the risk of business email compromise. I recommend against it and request written approval from [the board/the CTO] if this exemption is to proceed.” Put the risk in writing. If they still insist, the decision is theirs, but the risk acceptance is documented.
To set up a FIDO2 key for any user, navigate to entra.microsoft.com → Users → select the user → Authentication methods → Add authentication method → FIDO2 Security Key. The user inserts the key into their USB port (or taps it for NFC), creates a PIN, and touches the key to complete registration. The entire process takes under three minutes. After registration, the user signs in by entering their username, inserting the key, entering the PIN, and touching the key. No phone, no app, no code. For users who travel frequently and worry about losing the key, register two keys — a primary and a backup stored in a secure location.
Temporary Access Passes solve the chicken-and-egg problem for new employees and contractors. When a new user needs to register for MFA but cannot sign in without MFA to reach the registration page, a Temporary Access Pass provides a one-time or time-limited passcode that satisfies the MFA requirement long enough for the user to register their permanent MFA method. Navigate to entra.microsoft.com → Users → select the user → Authentication methods → Add authentication method → Temporary Access Pass. Set the lifetime (default is 1 hour, configurable from 10 minutes to 30 days) and whether it is one-time use or multi-use. Give the pass to the user, they sign in with their password plus the TAP, and then register Microsoft Authenticator or a FIDO2 key during that session. The TAP expires automatically. In practice, most executive resistance dissolves when you demonstrate the FIDO2 key experience. A 2-second touch on a physical key is less friction than typing a password. Offer a 10-minute setup session with the executive’s assistant present. Once configured, most executives forget MFA exists because the FIDO2 key is seamless.
Practical FIDO2 key deployment
If you’re going to deploy FIDO2 keys for any users, here’s the procurement and configuration process.
What to buy. Yubico YubiKey 5 series is the most widely supported. The YubiKey 5 NFC (USB-A + NFC, £40-50) works with laptops and phones. The YubiKey 5C NFC (USB-C + NFC, £45-55) is better for modern laptops and phones. Buy two per user — a primary and a backup. Store the backup in a secure location. Total cost per user: £80-110, one-time purchase with no subscription.
Enable FIDO2 in your tenant. Navigate to entra.microsoft.com → Protection → Authentication methods → Policies → FIDO2 security key. Set to “Enable.” Under “Target,” select the users or groups who will use FIDO2 keys. Under “Configure,” ensure “Allow self-service set up” is Yes and “Enforce attestation” is Yes (this verifies the key is a genuine FIDO2-certified device, not a software emulator).
Register the key for a user. The user navigates to aka.ms/mysecurityinfo → Add sign-in method → Security key → USB device. They insert the key, create a PIN (this PIN is device-local — it never leaves the key), and touch the key to complete registration. Total time: under 3 minutes.
Test the sign-in. The user signs out and signs back in. At the sign-in page, they click “Sign-in options” → “Security key.” They insert the key, enter the PIN, and touch the key. Sign-in completes. Total interaction: 5 seconds.
For shared workstation scenarios (manufacturing floor, reception desk), the FIDO2 key stays with the user on a lanyard or keychain — not attached to the workstation. Each user taps their own key to sign in, ensuring individual accountability even on shared hardware.
Shared and service accounts
Shared mailboxes in M365 should not have interactive sign-in enabled. Navigate to the M365 Admin Center → Users → Active users → select the shared mailbox → “Block sign-in” toggle → set to “Yes.” Users access the shared mailbox through delegation — it appears in their Outlook automatically because they have Full Access permission. No separate sign-in, no separate MFA. If your shared mailboxes currently have interactive sign-in enabled, disabling it is an immediate security improvement.
Service accounts that authenticate to Microsoft Graph API or other M365 services should use app registrations with certificate-based authentication or managed identities — never user accounts with passwords. Navigate to entra.microsoft.com → App registrations → New registration. Create an app registration for the service, generate a certificate, upload the public key, and configure the application to authenticate with the certificate. No password, no MFA prompt, no user account to compromise. This is more secure than any MFA method because there’s no credential to phish.
If the legacy application vendor says they plan to support modern authentication “in the next release,” get a specific date in writing and add it to your exception register review date. Vendor “soon” often means 6-18 months. Your exception register keeps you honest about how long you have been accepting the risk, and gives you the data to justify switching vendors if modern auth support never materialises. For service accounts that absolutely must use user-based authentication (legacy applications that can’t be reconfigured), use a dedicated service account with the minimum required permissions, a 25+ character randomly generated password, and conditional access policies that restrict sign-in to specific IP addresses. This isn’t ideal, but it’s better than a shared password with no restrictions.
Room and resource accounts
Conference room accounts (for Teams Rooms devices) and resource mailboxes (for room booking) don’t need interactive sign-in. Room mailboxes should be configured as resource accounts in the M365 Admin Center, which disables interactive sign-in by default. Teams Rooms devices authenticate using device accounts with specific Teams Rooms licenses — they don’t use standard user MFA flow.
If you have room accounts that are currently set up as regular user accounts with passwords shared among staff, convert them to resource mailboxes. This eliminates the password-sharing problem entirely and removes the accounts from the MFA exception conversation.
Building the exception register
Every exception must be documented. Create a simple register (a SharePoint list or Excel file works) with these columns: Account name, Exception type, Approved solution, Justification, Approved by, Date approved, Review date. Set review dates quarterly. Every quarter, check whether the exception is still needed — legacy systems get upgraded, contractors finish their contracts, and service accounts can be migrated to managed identities over time.
The quarterly review is not optional — it is the control that prevents your exception register from becoming a permanent collection of security gaps. In each quarterly review, check three things for every exception: is the exception still needed (did the contractor leave? did the vendor release modern auth support? did the shared workstation get individual accounts?), is the approved solution still in place (is the IP restriction still active? is the FIDO2 key still registered? is the sign-in still blocked on the shared mailbox?), and has the risk level changed (did the service account get additional permissions that increase the blast radius if compromised?). Remove exceptions that are no longer needed. Escalate exceptions where the risk has increased. Document the review outcome. This takes 15 minutes per quarter and prevents the slow erosion of your MFA coverage that happens when exceptions are approved and forgotten. A practical tip for the exception register: create it as a SharePoint list rather than an Excel file. A SharePoint list supports column filtering, version history, automated reminders (via Power Automate for the quarterly review), and access control — you can share it with your manager for visibility without giving them edit access. Create columns for Account Name (single line text), Exception Type (choice: Executive, Shared Account, Service Account, Room Account, BYOD, Other), Approved Solution (multi-line text), Justification (multi-line text), Approved By (person), Date Approved (date), and Review Date (date). Set a reminder flow that emails you 7 days before each review date. The discipline is this: no exception exists without a documented justification, an approved alternative that doesn’t include “exempt from MFA,” and a review date. This prevents the accumulation of permanent gaps that grows over years until your MFA policy has more holes than coverage.
The manufacturing floor has three shared workstations used by shift workers. Each workstation has a shared Windows account and a shared M365 account that all shift workers use to check email and access the shift schedule in SharePoint. You need to enforce MFA, but 15 workers share each account and nobody has individual credentials for these workstations. What do you do?
Option A: Exempt the three shared accounts from MFA since shared workstations can’t practically support per-user MFA.
Option B: Issue each shift worker their own M365 account, deploy FIDO2 security keys on lanyards, and configure the shared workstations for kiosk mode with shared device sign-out.
Option C: Keep the shared accounts but add a FIDO2 key physically attached to each workstation that anyone can tap to complete MFA.
The correct answer is Option B. Individual accounts with FIDO2 keys provide accountability (you know who accessed what), eliminate password sharing, and support proper MFA. A FIDO2 key on a lanyard is practical for manufacturing workers — tap the key to sign in, pull the key to sign out. Option C (a shared FIDO2 key) provides MFA in name but no accountability — it’s the security equivalent of a shared password plus a shared key, which doesn’t verify individual identity. Option A creates three permanently unprotected accounts.
Try it: Audit your shared and service accounts
Navigate to the M365 Admin Center → Users → Active users. Click the filter dropdown and select “Shared mailboxes.” Check each shared mailbox: is “Sign-in blocked” set to Yes? If not, you have shared mailboxes with interactive sign-in enabled — each one is a potential MFA exception you need to resolve.
Now search for service accounts — look for accounts with names like “svc-”, “service-”, “app-”, or accounts that don’t correspond to real employees. For each one, check: does it have an interactive sign-in in the last 90 days (check the Entra sign-in log)? Is it using legacy authentication? Could it be converted to an app registration with certificate-based auth?
Document every shared and service account you find. For each, note: the current authentication method, whether it’s exempted from MFA, and the recommended migration path (disable sign-in, convert to app registration, or deploy FIDO2 key). This is your exception register baseline.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.