Cyber Insurance for Microsoft 365 Tenants: The 2026 Attestation Checklist

If your client runs on Microsoft 365, a large share of their cyber-insurance attestation burden already lives inside Microsoft’s admin surfaces.

That does not mean Microsoft 365 answers every underwriting question.

It does mean that many of the most important answers — MFA, admin coverage, mailbox security, device encryption, managed-device inventory, and endpoint visibility — are already scattered across Entra, Exchange Online, Defender, and Intune.

That is the practical problem BindLedger is solving.

Carriers do not ask, “Which Microsoft portal should I look in?” They ask things like:

• Is MFA required for email, VPN, remote access, and privileged accounts?
• Are devices encrypted?
• Is endpoint protection active on all devices?
• Are backups isolated and tested?
• Are email-security controls in place?

The MSP then has to turn tenant data into a clean, defendable carrier answer.

This guide maps the main M365 services to the actual carrier forms BindLedger is built around.

For the carrier-form side of that mapping, pair this page with How to Answer the Coalition Cyber Insurance Application and the Travelers CyberRisk Short Form Guide.

The carrier map at a glance

That last row is important. Microsoft 365 is a huge part of the answer. It is not the entire answer.

1. Entra ID: the center of gravity for MFA and privileged-access evidence

If there is one Microsoft service that matters most for cyber insurance, it is Entra ID.

Which carrier questions it maps to

• Coalition CYUSP-00NA-1022-01, Question 6a: MFA for email.[1]
• Coalition Question 6b: MFA for VPN access.[1]
• Coalition Question 6c: MFA for RDP / RDWeb / RD Gateway or other remote-access technology.[1]
• Coalition Question 6d: MFA for privileged administrative accounts.[1]
• Travelers CYB-14203 Question 3i: MFA for remote access to email and other systems containing sensitive data in bulk.[2]
• Travelers CYB-14306 Question 1: MFA for all employees accessing email through a website or cloud service.[3]
• Travelers CYB-14306 Question 2: MFA for all remote access to the network.[3]
• Travelers CYB-14306 Question 3a–3d: MFA for directory services, backup environments, network infrastructure, and endpoints / servers.[3]
• The Hartford CB 00 H027 03 0824 Section 7: MFA for all remote network access and MFA for email access.[4]

What Microsoft actually gives you

Microsoft gives you the raw ingredients, not the final attestation.

• Security Defaults tell you whether the tenant is using Microsoft’s baseline enforcement model.[5]
• Conditional Access policies are retrievable through Microsoft Graph and expose policy scope, conditions, and exclusions.[6]
• userRegistrationDetails exposes whether a user is admin, MFA-capable, and MFA-registered.[7]

This is exactly why there is no one-click insurer report in Microsoft 365.

The carrier question is “is MFA enforced?” Microsoft gives you three separate evidence surfaces you still have to reconcile.

That is the exact problem unpacked in The M365 MFA Reporting Gap.

The key M365 reality MSPs need to remember

isMfaRegistered is not the same thing as “this user is definitely enforced on every relevant path.”[7]

That is why BindLedger treats Entra as the identity evidence source, not as a one-field answer.

2. Exchange Online and DNS: the email-authentication layer insurers increasingly care about

Email-related underwriting lives partly inside Microsoft 365 and partly outside it.

Which carrier questions it maps to

• Hartford CB 00 H027 03 0824 Section 7 asks about SEG, malicious attachments, malicious links, external sender tagging, and training cadence.[4]
• Hartford ransomware supplemental Section 1 asks which protocols authenticate the sender and content of emails and which Office 365 security add-ons are used.[8]
• Coalition does not ask SPF / DKIM / DMARC directly on the current public PDF, but Coalition Control scans external attack surfaces monthly and uses DNS-related signals in its findings.[9]

What Microsoft actually gives you

• Exchange Online and Microsoft 365 tenant configuration are where you enable or manage DKIM, mail-flow rules, and parts of sender handling.
• DNS is where SPF and DMARC live publicly.
• Microsoft’s own documentation covers SPF, DKIM, and DMARC setup for Microsoft 365 domains.[10][11][12]

What M365 can and cannot prove here

M365 plus DNS can prove a lot about sender-authentication posture.

It cannot, by itself, prove every email-control answer on a Hartford-style form. External sender tagging, SEG configuration, and malicious attachment / link handling often require tenant inspection beyond DNS alone.

That is why BindLedger’s /scan page is the first step, not the whole email story.

For the DNS-first version of that conversation, see DMARC, SPF, and DKIM for Cyber Insurance.

3. Defender for Business: the fastest answer to “do you have endpoint protection everywhere?”

Travelers’ short form asks whether the applicant has active anti-virus software on all computers, networks, and mobile devices.[2] Hartford’s current underwriting application asks whether antimalware, antivirus, and/or endpoint detection is running on computers, networks, and mobile devices, and whether an EDR or MDR product is in place.[4]

Which carrier questions it maps to

• Travelers CYB-14203 Q3b.[2]
• The Hartford CB 00 H027 03 0824 Section 7 Endpoint Protection.[4]

What Microsoft actually gives you

Microsoft Defender for Business gives administrators a device inventory in the Defender portal under Assets > Devices, where they can view onboarded devices and associated health context.[13]

That is extremely useful for underwriting evidence because it turns the conversation from “we use Defender” into “here is the list of onboarded devices and their health state.”

Where the gap still exists

Defender for Business can show onboarded devices and antivirus state.[13] It still does not, on its own, answer whether every device the business owns or uses is in scope.

That is a device-governance question, not just a security-tool question.

This is another recurring underwriting pattern: the security console is strong on covered assets, weaker on unknown or unmanaged assets.

4. Intune: the strongest M365 answer to device encryption questions

Device encryption is one of the easiest places to move from hand-waving to evidence.

Which carrier questions it maps to

• Coalition CYUSP-00NA-1022-01 Question 3 asks whether laptops, desktops, and portable media containing confidential information are encrypted.[1]
• Travelers CYB-14203 Q6a–Q6e asks about encryption at rest, in transit, on mobile devices, on employee-owned devices, and at third-party service providers.[2]
• Hartford CB 00 H027 03 0824 Section 6 asks whether nonpublic personal records are encrypted while at rest, in transit, and on mobile devices.[4]

What Microsoft actually gives you

Intune’s encryption report is a centralized view of device encryption status. Microsoft documents that the report shows device encryption status, readiness, and related details, and can be exported to CSV for the devices you manage.[14]

That makes Intune one of the cleanest native evidence sources for encryption attestation.

What Intune still does not solve by itself

The qualifier is “for the devices you manage.”

If the client has unmanaged laptops, personally owned phones outside the MDM boundary, or devices that have not checked in recently, Intune evidence is still partial evidence.

It is high-quality partial evidence — but it is still partial.

5. What Microsoft 365 does not answer alone

This is the part too many M365-focused renewal guides skip.

A Microsoft 365 tenant can answer a lot. It cannot honestly answer everything.

Backup isolation and restore testing

Coalition Q5, Travelers Q3d, and Hartford Section 6 backup questions are not answered by Microsoft 365 alone.[1][2][4]

You still need a backup platform and evidence source outside M365 to prove:

• backup frequency,
• immutability or isolation,
• restore testing,
• coverage for critical systems beyond Microsoft 365 data.

That off-platform evidence is the subject of How to Prove Backup Immutability for Cyber Insurance Renewals.

Callback procedures and funds-transfer controls

Coalition Q7 and Travelers’ social engineering fraud supplements ask about secondary validation, direct calls to known numbers, dual authorization, and other payment-process controls.[1][15][16]

Those are not tenant settings. They are operational controls.

Incident response and continuity documentation

Travelers Q3e and Q3f, and Hartford’s continuity questions, still require documented plans and testing, not just technology evidence.[2][4]

6. The practical M365 evidence pack for renewal season

If you want a Microsoft 365-centered renewal process that reads professionally to a broker, build the packet in layers.

Layer 1: identity

• Security Defaults status,
• Conditional Access policies requiring MFA,
• exclusions and exception groups,
• admin-role holders,
• userRegistrationDetails summary.

Layer 2: email

• domain scan for SPF / DKIM / DMARC,
• external sender tagging status,
• mail security stack summary,
• mailbox MFA enforcement summary.

Layer 3: devices

• Defender device inventory,
• antivirus or endpoint-health summary,
• Intune managed-device count,
• unmanaged-device exception list if known.

Layer 4: encryption

• Intune encryption export,
• BitLocker / FileVault status summary,
• BYOD limitations if applicable.

Layer 5: non-M365 dependencies

• backup platform evidence,
• payment-control documentation,
• IR / BCP documentation,
• exception register.

That is the architecture of a serious attestation process.

Why this should be the BindLedger pillar page

This page is the strategic center of the content plan because it mirrors the product architecture.

• The DNS scanner supports the email section now.
• The M365 connector supports the Entra / Intune / Defender sections next.
• The backup connectors support the off-platform recovery section after that.

That creates a clean internal-linking model too:

• link the MFA section to the M365 MFA article,
• link the email section to the DMARC / SPF / DKIM article,
• link the backup section to the backup immutability article,
• link the claims relevance to the BEC / FTF article,
• link the lifecycle view to the renewal-drift article.

In practice, that reading path looks like:

• The M365 MFA Reporting Gap
• DMARC, SPF, and DKIM for Cyber Insurance
• How to Prove Backup Immutability for Cyber Insurance Renewals
• BEC and Funds Transfer Fraud Coverage
• Cyber Insurance Mid-Term Audits and Renewal Drift

That is not just SEO structure. It is product education structure.

What to do right now

If you are a Microsoft 365-heavy MSP, start where your evidence is easiest to make public: your email domain.

Primary CTA: Start your M365 attestation baseline by scanning your email domain now at bindledger.com/scan.

Secondary CTA: Then enter your email on BindLedger to get notified when full tenant scanning launches for Entra, Intune, Defender, and carrier-mapped M365 evidence reports.