Proving MFA and privileged access: the evidence insurers and auditors actually accept
Cyber insurance MFA requirements and SOC 2 access control evidence decoded: the MFA audit evidence and PAM records that underwriters and auditors accept.
Why identity controls pass in practice and fail on paper
Three failure modes account for almost every gap I have seen between a working control and a defensible one.
Coverage you cannot see. The policy blade shows the rule. It does not show the exclusion group added during a Teams Rooms rollout, the six accounts still in per-user MFA legacy state, the policy sitting in report-only mode since the pilot, or the SMTP AUTH path a scanner still uses. Your Conditional Access summary reads as full coverage while the sign-in log tells a different story.
Evidence that describes configuration rather than outcome. A screenshot of a policy set to require MFA proves that the policy existed on the day of the screenshot. It says nothing about whether every in-scope authentication was actually challenged, whether an exclusion swallowed a population, or whether the state held for twelve months.
The control assessment framework that most auditors work from makes this distinction operational: the CIS access control safeguards ask an assessor to enumerate accounts properly configured to require MFA and separately enumerate administrative accounts not properly configured to require MFA. The delta between those two lists is the finding.
The lookback problem. Attestations cover a period. A SOC 2 Type 2 observation window typically runs three, six, or twelve months. A claims investigation looks back from the incident date to the application date.
You cannot produce authentication records for a period you did not capture, and no amount of remediation after the fact creates them. Retention is the one control in this entire exercise that cannot be retrofitted, which is why it belongs at the front of the sequence rather than the end.
This is the same dynamic that turns an insurance conversation into an architecture conversation, which is why the renewal cycle now sets the security roadmap at a lot of organisations rather than following it.
What the questionnaire language actually means
Underwriters and auditors compress enormous scope into short phrases. Reading them literally is how organisations end up making inaccurate attestations in good faith.
All remote access means every authenticated path originating outside the network perimeter. VPN concentrators, RDP and Remote Desktop Gateway, RD Web Access, published Citrix or AVD workspaces, ZTNA brokers, jump hosts, and for anyone running managed services, the RMM console.
The payment card standard states this scope without ambiguity in requirement 8.4.3, which covers all remote network access originating from outside the entity's network, and explicitly extends to administrators, personnel, third parties, and vendors.
All privileged accounts means cloud directory roles, on-premises Active Directory privileged groups, local administrator accounts on endpoints and servers, hypervisor and storage array administrators, backup console operators, and privileged service accounts.
Carrier proposal forms increasingly name the on-premises directory directly and ask the applicant to justify the count of accounts holding full directory access. A tally of Global Administrators answers a fraction of that question.
No shared credentials means unique attributable identity per human. A shared svc-admin login rotated between three engineers fails this regardless of how well the password is vaulted, because the audit trail cannot attribute an action to a person.
Enforced across the organisation means no material exemptions. This is where the ambiguity bites hardest, and it bites in six predictable places: service accounts with interactive logon rights, break-glass accounts, legacy authentication protocols, on-premises AD administrators outside cloud policy scope, standing local administrator rights, and contractor access provisioned outside the identity platform.
The consequence of getting this wrong is contractual rather than reputational. The application is a warranty. In Travelers Property Casualty Company of America v. International Control Services, filed in the Central District of Illinois in July 2022, the carrier moved to rescind a $1 million cyber policy after a ransomware event, alleging the insured had misrepresented enterprise-wide MFA on a signed application. The investigation found MFA present on the firewall and absent on the server where the intrusion originated. The parties stipulated to rescission the following month and the policy was void from inception.
That case matters less as precedent than as a description of method. The carrier reconstructed the actual authentication posture from forensic artefacts and compared it against the attestation. Your evidence pack should survive the same treatment.
The evidence matrix for identity controls
The framework text sets outcomes and leaves the artefact to the auditor's judgement. The Trust Services Criteria require that the entity implement logical access security software, infrastructure, and architectures over protected information assets under CC6.1, that credentials be registered and authorized before issuance and removed when access is no longer authorized under CC6.2, and that access be granted with consideration to least privilege and segregation of duties under CC6.3.
None of those criteria specify a report format or a retention period. The auditor selects samples across the observation window, and what you can produce for a sampled date determines the outcome.
Reading the matrix below: column three is the answer that gets given in the kick-off call and survives about four minutes of follow-up. Column four is the question that ends it. Column five is what you should already have running.
Three technical notes on producing column five in a Microsoft estate.
First, sign-in evidence lives in the SigninLogs table once diagnostic settings are exporting, and the fields that matter are AuthenticationRequirement, ConditionalAccessStatus, AuthenticationDetails, and ClientAppUsed.
A query filtering ConditionalAccessStatus == "notApplied" over ninety days surfaces your real coverage gap faster than any policy review.
Second, interactive sign-ins are a subset: AADNonInteractiveUserSignInLogs and ServicePrincipalSignInLogs are separate diagnostic categories and both need enabling explicitly.
Third, registration is not enforcement, and the /reports/authenticationMethods/userRegistrationDetails Graph endpoint answers the registration question only.
What tightly controlled admin accounts means in evidence terms
The phrase resolves into six provable elements. Each one has a specific artefact, and each artefact has a retention characteristic worth checking before you rely on it.
Privileged inventory completeness is the element auditors probe first, because it is the one you cannot bluff. Completeness means a documented derivation method: directory role assignments, the AD groups protected by AdminSDHolder, accounts carrying a non-zero adminCount attribute, and local Administrators group membership collected from every endpoint.
Just-in-time elevation produces an activation record naming the requester, the role, the justification, the duration, and the approver. Entra Privileged Identity Management keeps that audit history for the past 30 days in the portal, which is shorter than any observation window you will be assessed against. Route it to Azure Monitor on day one.
Break-glass is where documentation and evidence diverge most sharply. Microsoft's own guidance has you maintain emergency access accounts excluded from Conditional Access, which means the exclusion is deliberate and defensible.
What makes it defensible is the test record proving the procedure was exercised, with the credential rotated afterwards.
The five gaps that fail renewals most often
Credential abuse is the reason underwriters ask these questions at all. It led initial access vectors for the second consecutive year at 22% of breaches, ahead of vulnerability exploitation at 20%, and 54% of ransomware victims had corporate credentials appearing in infostealer logs.
Perimeter appliances including VPN and firewall products featured in 58% of ransomware claims in one carrier's claims dataset. The five gaps below are where those vectors meet your attestation.
Service accounts with static credentials and no second factor. Found by querying ServicePrincipalSignInLogs and AADNonInteractiveUserSignInLogs, and on-premises by looking for accounts with PasswordNeverExpires holding interactive logon rights.
Closed by migrating to managed identities or group Managed Service Accounts where the workload supports it, vaulting the remainder with scheduled rotation, and documenting each residual exception with a compensating control. Non-interactive workload identity cannot satisfy an interactive challenge, and saying so plainly in the questionnaire is a stronger position than a bare yes.
Legacy authentication paths still enabled. Found by filtering sign-ins on ClientAppUsed for IMAP4, POP3, SMTP AUTH, Exchange ActiveSync and the catch-all Other clients value. Closed by a Conditional Access policy blocking legacy clients, with the caveat that SMTP AUTH is often still enabled per-mailbox for multifunction devices and application relays. Those mailboxes are your exception list.
On-premises AD administrators outside cloud identity policy. Found by diffing membership of Domain Admins, Enterprise Admins, Account Operators and Backup Operators against the population your Conditional Access policies actually evaluate.
Kerberos and NTLM authentications never traverse cloud policy, so a domain admin logging on to a member server is invisible to your tenant-level evidence. Closed by extending MFA to interactive server logon and consolidating identity, which is one of the strongest arguments for moving on-premises Active Directory into Entra ID rather than maintaining two policy planes. Where consolidation is not on the table, the failure patterns are well documented in hybrid Okta and AD environments and worth reading before you attest.
Standing local administrator rights on endpoints. Found through endpoint inventory of the local Administrators group, or via advanced hunting across managed devices. Closed by removing standing rights, deploying Windows LAPS for the built-in account, and moving day-to-day elevation to an on-demand model that leaves a record.
Third-party and contractor access outside the identity platform. Found by reconciling every vendor and contractor account against the directory, including accounts created directly on appliances, jump hosts and SaaS admin consoles.
Closed by federating that access, time-boxing it, and brokering it through a ZTNA service that enforces identity per connection rather than a VPN account that grants network-level reach.
What this means for your IAM and PAM shortlist
Feature comparisons are the wrong starting point when the deliverable is evidence. Derive the requirements from the artefacts you are obliged to produce, then test candidates against them.
The decisive question for any platform on the shortlist: can it produce, on demand, a per-account report of MFA outcome across a twelve-month lookback, including every exemption? A platform that reports policy state rather than per-account outcome will pass a demo and fail an audit.
Retention specifics are the most common surprise. Entra ID retains sign-in and audit logs for 7 days on the free tier and 30 days with P1 or P2, with longer retention available only through diagnostic settings export.
Okta retains System Log events for 90 days, accessible through the /api/v1/logs endpoint for export. CyberArk documents session retention as configurable per safe. Every one of those defaults sits below a twelve-month attestation window.
Two adjacent decisions follow from this. If your IAM platform is genuinely in play rather than settled, the reporting and governance differences across Ping, Okta and OneLogin matter more than the SSO feature parity that dominates most comparisons.
And if you are producing this evidence repeatedly across multiple frameworks, a compliance automation platform is worth evaluating on the depth of its identity integrations specifically, because that is where the collectors are thinnest.
Requirements to put in writing
Evidence obligations belong in the contract rather than in a hopeful assumption about the vendor's roadmap. The retention figures below track the payment card standard, which requires audit log history be retained for at least twelve months with the most recent three months immediately available. That gives you a defensible, framework-anchored baseline to negotiate from.
Clause 6 is the one most people leave out and later need. Retention defaults change with licensing changes, and a silent reduction mid-window destroys evidence you were relying on.
What to have ready before the renewal date
Work backwards from two fixed dates: the policy renewal, and the start of your next audit observation window. The application typically needs submitting several weeks ahead of renewal, and the observation window opens well before the auditor arrives.
The evidence pack itself is short. Current Conditional Access policy exports with full exclusion lists. Per-account authentication method and outcome reports.
A dated privileged account inventory reconciled across cloud, AD and endpoints, with the derivation method written down. PIM or PAM activation records with approvals.
Access review exports showing population, reviewer, date and revocations. The break-glass test record. Deprovisioning evidence for recent leavers, timestamped against termination dates.
A written exception register covering service accounts, SMTP AUTH mailboxes and break-glass accounts, each with a compensating control.
Sequencing is the part that decides whether this works. Configure diagnostic export before anything else, because retention is the only item on that list you cannot produce retrospectively.
Enable every relevant category, including non-interactive and service principal sign-ins, and confirm the data is arriving in your workspace rather than assuming the setting took effect.
Then run the gap queries. If your retention window is shorter than your longest attestation lookback, treat that as a hard stop and fix it before touching anything else.
Everything downstream inherits that limitation, and a perfect control with no record of its operation reads, to an auditor or a claims adjuster, exactly like no control at all.
Find the IAM and PAM platforms that can produce evidence
Find vendors who can help you report per account MFA-outcome on a curated platform of pre-vetted technology vendors. Vendor can't cold outreach to you so you start conversations on your terms when your ready. It's free and private.
FAQ
Does MFA on email satisfy a cyber insurance requirement?
No. Carrier applications ask separately about email, VPN, remote desktop, and network or cloud administrative accounts, and increasingly about backup infrastructure. Answering yes on the strength of email alone addresses one surface out of four or five. Read each sub-question as a distinct attestation, because that is how it will be assessed at claim time.
What counts as a privileged account?
Any account with elevated or administrative permissions over systems, data or identity. That includes cloud directory roles, AD privileged groups, local administrators, hypervisor and storage administrators, backup console operators, SaaS tenant admins, and service accounts holding administrative rights. Carrier forms often name full directory access specifically and ask you to justify the count.
Do service accounts need MFA?
Interactive service accounts should be eliminated or converted. True non-interactive workload identities cannot satisfy an interactive challenge, so the control set is different: managed identities or gMSAs where supported, vaulting with scheduled rotation elsewhere, conditional access for workload identities where licensed, and a documented exception register. State this explicitly rather than answering yes.
Will an insurer accept a screenshot?
For underwriting, often yes. At claim time, no. A screenshot evidences configuration on one date, and investigators reconstruct the actual authentication posture from logs and forensic artefacts, which is precisely what happened in the Travelers matter. Build the log-based evidence on the assumption it will be tested.
How long do authentication logs need to be retained?
There is no universal figure. The payment card standard requires twelve months with three immediately available, and a SOC 2 Type 2 window commonly runs three to twelve months. Align to your longest applicable obligation and add a margin. Platform defaults of 7, 30 or 90 days all fall short, so export.
Is Conditional Access the same as MFA enforcement?
No. Conditional Access is the mechanism that can enforce MFA. Enforcement is the observed outcome. A policy in report-only mode, or one carrying an exclusion group, exists without enforcing anything for that population. Evidence enforcement through sign-in records showing the policy applied and the factor satisfied.
Do we need a PAM product or is Entra enough?
Entra PIM provides just-in-time elevation, approval workflow and activation records, with 30 days of portal audit history. It does not provide session recording, credential vaulting for non-directory targets, or rotation evidence for appliance and database accounts. If your privileged estate is materially outside the directory, or your framework requires session evidence, a dedicated PAM platform covers ground Entra does not.
What evidence does SOC 2 require for logical access?
The criteria prescribe outcomes rather than artefacts. CC6.1 through CC6.3 cover access security, authorised provisioning with removal when access is no longer authorised, and least privilege. Auditors typically sample provisioning and deprovisioning records, access reviews, and authentication configuration across the observation period, then test whether the control operated throughout.
