How should MFA exceptions be documented and reviewed for a cyber-insurance questionnaire?

Cyber-insurance applications stopped asking whether you use MFA years ago — coverage is assumed. The question that decides pricing and subjectivities now is the follow-up: "Are there exceptions, and are they documented, approved, and reviewed?" This page explains how underwriters read that answer, gives you a register template that satisfies it, and shows the one move that shrinks the list the most: taking break-glass access off it entirely.

What the question is really probing

An underwriter reading an MFA-exception answer is scoring three things:

1. Awareness. Do you actually know where MFA doesn't apply? An answer of "no exceptions" from an organization running service accounts, legacy IMAP, network appliances, or an emergency admin account signals that nobody has looked. Unknown exceptions are how ransomware operators get in; that's precisely what the carrier is pricing.
2. Ownership and compensating controls. For each exception: who owns it, why does it exist, and what stands in for MFA — network restriction, credential vaulting, alerting, session recording?
3. Trajectory. Is the list reviewed on a schedule, and does it ever shrink? A dated review trail with removals is the difference between a managed register and a spreadsheet of permanent risk acceptances.

The exception register template

Copy this into your GRC tool or a version-controlled document. One row per exception:

Field	What to record
System / account	The specific account or protocol excluded from MFA (not "various")
Reason	Why MFA cannot apply — technical constraint, vendor limitation, availability requirement
Owner	A named person, not a team
Compensating controls	What replaces MFA: IP allowlisting, vaulted credentials, conditional access, alert-on-use, session recording
Approved by / date	Who accepted the risk and when
Review cadence	Quarterly is the common default
Last reviewed / outcome	Date + kept / modified / removed
Target end date	When this exception should die (or "standing", with justification)

Two rules make the register credible in front of an underwriter:

• Every row has an end state. Either a date the exception retires, or an explicit, argued reason it is permanent.
• Reviews leave evidence. A calendar reminder is not a review. A dated sign-off — ideally with at least one removal per year — is.

The biggest single improvement: no break-glass exception at all

The most damaging row on most registers is the emergency one: a standing, MFA-exempt admin account "in case the IdP is down." It is the highest-value credential in the environment with the weakest protection — and every attacker knows to look for it.

The pattern underwriters respond well to removes the row instead of defending it:

• No standing exempt account. Emergency credentials are sealed, split among named responders, and reassembled only under quorum approval — no individual can quietly use them.
• Alert-on-access, always. Any release of break-glass material notifies the security owner and lands in an append-only log the user of the credential cannot edit.
• Independent of the identity plane. The emergency path works when the IdP itself is the casualty — which is exactly the scenario the exception was created for, handled without a permanent hole in MFA enforcement.
• Evidenced. Every activation (real or drill) produces a timestamped record you can attach to next year's questionnaire.

On the application, that converts "yes, we have an MFA-exempt emergency account" into: "Emergency access is quorum-gated and logged outside the MFA-exception process; the exception register contains no break-glass entries." The first answer starts a follow-up conversation; the second usually ends one.

How Glassbreak fits (and honest limits)

Glassbreak stores break-glass credentials end-to-end encrypted and split M-of-N across your responders, so decryption requires quorum approval and every access is attributed and timestamped. The evidence pack export maps those controls to the recurring insurance-questionnaire themes, alongside ISO 27001 Annex A, DORA, and NIS2.

The honest limits: Glassbreak is not an insurer, and nothing here is a guarantee of coverage or premium — underwriting is the carrier's decision. Glassbreak is also not ISO 27001 or SOC 2 certified (our program is ISO-aligned; the product generates your evidence, not ours). For the wider set of privileged-access questions on the application, see the cyber-insurance questionnaire prep guide, and for the procedure document auditors sample, the ISO 27001 break-glass procedure template.