Microsoft Secures Microsoft. Securing Your Tenant Is Your Job.

Buying Microsoft 365 or Google Workspace isn't a security decision, a compliance decision, or a decision at all about who is responsible when something goes wrong. It's a purchase, and the responsibility it transfers is narrower than almost everyone assumes.

The shared responsibility model is the division of security duties between a cloud provider and its customer: the vendor secures the platform, and the customer secures what they put on it and who can reach it. For software as a service, that split is documented, not debatable.

Microsoft publishes it. In its own shared responsibility documentation, the customer retains customer data, configurations and settings, and identities and users under every deployment model including SaaS. Microsoft owns the physical datacenter, the physical network, the physical hosts, the operating system, and network controls. Applications and client devices are shared.

Read the customer column again. Data, configuration, identities, access. That's not the leftovers. That's every dimension an attacker actually uses.

What does Microsoft say you're responsible for?

Verbatim from that same document, listing what the customer retains regardless of deployment type:

> "Data - You're responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements. Endpoints - You're responsible for protecting client devices and endpoints... Accounts - You're responsible for managing user accounts... Access management - You're responsible for implementing and managing access controls, including role-based access control (RBAC), multifactor authentication, and conditional access policies."

Microsoft is not being coy about this. The division is published, and it's the same division for Google Workspace. If you want the plain-English version of why this catches people out, we covered it in Why Your Software Isn't as Safe as You Think. This piece is the admin-console version of the same argument. What creates the gap is that nothing in the purchase process makes you read it, and the product works perfectly well while badly configured. A tenant with no conditional access, admin accounts used for daily email, and external sharing wide open sends and receives mail exactly as well as a hardened one. There's no error message for insecure.

Why doesn't MFA settle the question?

Because attackers stopped fighting MFA and started going around it.

The current technique is adversary-in-the-middle phishing: the victim lands on a proxy that relays a real login to the real service, the victim completes MFA correctly, and the attacker captures the resulting session token. With the token, no password and no second factor are needed. The session is already authenticated.

CISA and international partners documented this pattern in advisory AA24-057A, describing threat actors "using tokens to access their victims' accounts, without needing a password," alongside MFA push bombing, residential proxies used to blend sign-in traffic into normal ISP ranges, and registering their own devices on the victim's tenant to establish persistence.

The advisory's mitigations are the useful part: phishing-resistant MFA, "keep session lifetimes as short as practical," restrict device enrollment to authorized devices, disable dormant accounts, apply least privilege to service accounts, and monitor application and host logs rather than relying on IP-based detection.

Phishing resistance has a precise meaning here. NIST SP 800-63-4, finalized July 31, 2025, defines it as the authentication protocol's ability to prevent disclosure of secrets and valid outputs "to an impostor verifier... without relying on the vigilance of the claimant." In practice that's FIDO2/WebAuthn passkeys or certificate-based authentication. One-time codes from an authenticator app are not phishing-resistant, and SMS is weaker still. CISA's Implementing Phishing-Resistant MFA says the same thing more bluntly.

MFA is still worth having everywhere. It just isn't the finish line, and a tenant configured as though it is has one control doing the work of ten.

What settings actually decide the outcome?

A dozen, and most of them are free with licenses you already own.

1. MFA enforced for everyone, with no self-service exemptions. Not just admins, and not a setting individual users can turn off for themselves.
2. Admin accounts that aren't daily drivers. Microsoft's security planning guidance is direct: "Be sure to create separate accounts for users to do Global Administrator tasks," those accounts "should be cloud-only accounts with no ties to on-premises Active Directory," and administrators should "always do their day-to-day business as standard 'unprivileged' users."
3. Break-glass accounts, done Microsoft's way. At least two, cloud-only on the .onmicrosoft.com domain, excluded from blocking conditional access policies, secured with passkeys rather than a password in a safe, alerted on every use, and validated at least every 90 days (Microsoft, emergency access accounts).
4. A license tier that includes the controls your risk actually requires. Conditional access, device management, and data loss prevention live above certain tiers. Buying the cheap tier and then needing the control is a common and expensive sequence.
5. A signed Business Associate Agreement, if you handle PHI. HHS is unambiguous: a cloud provider maintaining ePHI is a business associate and a BAA is required, and encryption doesn't exempt them - "Lacking an encryption key for the encrypted data it receives and maintains does not exempt a CSP from business associate status." See our HIPAA page.
6. No personal or free accounts touching business data. Access you can't audit and can't revoke.
7. External sharing restricted and reviewed. Defaults are permissive.
8. Every device on the tenant recognized. Device registration is how attackers persist after a token theft.
9. Same-day offboarding, including session revocation. A disabled account with a live session is not a disabled account.
10. SPF, DKIM, and DMARC published and enforcing.
11. Audit logging on and retained long enough to matter.
12. Third-party app permissions reviewed. Consented app access survives a password reset. This is the one nobody checks.

What about backup and audit logs?

Two claims circulate constantly here, and both need correcting.

Audit log retention is 180 days, not 90. Microsoft changed the Audit (Standard) default from 90 days to 180 days for logs generated on or after October 17, 2023. Audit (Premium) retains Entra ID, Exchange, OneDrive and SharePoint records for one year by default, extendable to ten with an add-on (Microsoft Purview audit solutions). Practically: Business Premium and E3 give you 180 days, E5 gives you a year. Anyone quoting 90 days is working from pre-2023 information.

On backup, be careful what you're citing. The line that gets quoted at businesses - "you should have a regular backup plan" - comes from the Microsoft Services Agreement, which governs consumer Microsoft accounts. It is not the instrument governing a commercial tenant. Using it in a business conversation is sloppy, and I'd rather not do it.

What Microsoft does say, from documentation that applies to business tenants: the customer owns the data; there's a hard deletion clock after a subscription ends (30 days expired, 90 days disabled, with all customer data deleted no later than 180 days after termination, and immediate SharePoint and OneDrive deletion if you explicitly delete a subscription rather than letting it lapse); and Microsoft now sells its own first-party Microsoft 365 Backup product, citing "a ransomware attack that encrypts large swaths of your data, or instances of an internal accidental or malicious data deletion" as the reason you'd want it.

Microsoft selling a backup product for ransomware recovery is a stronger argument than a misquoted consumer agreement. Note that its coverage is Exchange Online, SharePoint, and OneDrive - Teams isn't on that list.

Is there a published standard for this?

Yes, and it's free. CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines for Microsoft 365 - Entra ID, Exchange Online, Defender for Office 365, SharePoint and OneDrive, Teams, Power Platform, and Power BI - along with an assessment tool called ScubaGear that scores a tenant against them. Federal civilian agencies have been required to implement them since BOD 25-01, issued December 17, 2024.

One honest caveat: SCuBA is scoped to federal agencies. CISA doesn't publish a recommendation that small businesses adopt it. But the baselines are public, and the reasoning behind each setting is documented, which makes them the best free reference available for what "configured properly" means.