Every organisation I walk into has bought the licences. Most have bought the expensive ones. And a striking number are running a tenant that is, functionally, the configuration it shipped with on the day it was provisioned. The licence was a procurement decision. The configuration was nobody's.
That distinction matters more than it used to, because the tenant is now the perimeter. The mail, the files, the identity provider and the device management all live in one place, reachable from anywhere with a password. There is no firewall in front of it. Under the current Cyber Essentials question set, missing multi-factor authentication on a cloud service that offers it is an outright fail rather than a finding, which tells you how the assessment world now views this.
This piece covers both Microsoft 365 and Google Workspace, because most estates end up with both, usually through an acquisition, and because the failure patterns rhyme even though the control names do not.
Why the defaults are the way they are
It is worth being fair to the vendors here, because understanding the incentive explains the whole problem. Both platforms are configured out of the box so that nothing breaks on day one. Open sharing so collaboration works. Permissive application consent so productivity tools install without a ticket. Legacy protocols enabled so the old scanner in the finance office still emails invoices. Every one of those defaults exists because the alternative generates support calls during a migration.
The result is a system that is safe to adopt and unsafe to leave alone. The controls you need are all present, most of them included in licences the organisation already holds, and switched off. Hardening a tenant is rarely a purchasing exercise. It is an ownership exercise.
The second structural issue is grant sprawl. In a traditional estate, administrative rights were something a small team held. In a tenant, ordinary users routinely hold the ability to share a file externally, consent to a third-party application reading their mailbox, invite a guest into a workspace, or set up forwarding. Each of those is a small delegation of authority. None of them individually looks like an admin right. Collectively they are the attack surface.
The technical detail
Identity, and the thing that is not MFA
Start here, because everything downstream assumes sign-in held. The target is phishing-resistant authentication: passkeys and FIDO2 security keys, or certificate-based authentication for the accounts that warrant it. Push notification approval and one-time codes are better than nothing and are no longer sufficient on their own, because both are defeated by an adversary-in-the-middle proxy that relays the session in real time. This is not theoretical: it is the standard technique of the groups currently working through UK retail and hospitality.
Two configuration errors recur. The first is treating a trusted office IP range as a second factor. It is not a factor, it is a location, and it is now explicitly not accepted as compliant MFA under the current Cyber Essentials criteria. The second is leaving legacy authentication protocols enabled. Anything speaking basic authentication bypasses conditional access entirely, which means every policy you wrote is decorative for that path.
On Microsoft 365 that means conditional access policies requiring phishing-resistant methods for administrative roles, blocking legacy authentication tenant-wide, and at least two break-glass accounts explicitly excluded from conditional access, with long random credentials held offline and monitored for use. On Google Workspace the equivalents are 2-step verification enforced with security keys, context-aware access, and enrolment in the Advanced Protection Program for high-risk accounts.
Applications, which is where the mailbox actually leaks
The most under-appreciated control in either platform is application consent. By default a user can authorise a third-party application to read their mail, files or calendar. The consent screen is a normal-looking sign-in dialogue. Nothing is compromised in the traditional sense, no password is stolen, and the resulting access survives a password reset because it is a separate grant with its own token.
The fix is to restrict user consent to applications from verified publishers with low-impact permissions only, and to route everything else through an admin consent workflow so requests become a queue an administrator sees rather than a decision an individual makes under time pressure. Then audit what is already consented, because the grants accumulated over the years before anybody looked are usually the interesting part.
Mail, forwarding and the persistence problem
Once inside a mailbox, the attacker's objective is durable access to the content. The classic mechanism is a forwarding rule, sometimes a client-side rule that hides itself from the web interface, sometimes a filter that forwards only messages matching finance-related keywords. Restrict automatic external forwarding at policy level rather than trying to detect each rule, and alert on the creation of new forwarding rules and inbox rules that move mail to obscure folders.
The other control worth the effort is external sender tagging, so a message claiming to come from the finance director carries a visible marker when it did not originate inside the tenant. It is unglamorous and it works, because the entire premise of business email compromise is that the recipient does not look closely.
Sharing, and the links you cannot see
Sharing links are the quietest of the failures because nothing appears broken. A document shared with anyone who has the link, created for a supplier in 2021, remains reachable indefinitely by anyone who ever had that URL, including in a forwarded email thread nobody can now retrieve.
Set default sharing to the least permissive option the business can tolerate, apply expiry to any link that can be created anonymously, and run a periodic review of guest accounts and externally shared content. Both platforms will report this. Very few organisations look at the report.
| Control | Microsoft 365 | Google Workspace |
|---|---|---|
| Phishing-resistant sign-in | Conditional access, passkeys, certificate-based auth | 2SV with security keys, Advanced Protection |
| Contextual policy | Conditional access | Context-aware access |
| App consent | Restricted consent plus admin consent workflow | API controls, app allow-listing |
| External forwarding | Outbound spam policy restriction | Gmail routing and forwarding controls |
| Sharing limits | SharePoint and OneDrive sharing policy, link expiry | Drive sharing settings, trusted domains |
| Audit | Unified audit log, alert policies | Admin audit and investigation tool |
Delivering it: who, what, when, deliverables, lineage
Who. Tenant configuration usually sits with an IT operations team or a managed service provider, and security often has read access at best. Decide early who can actually change a conditional access policy, because a hardening programme where the security team can only raise tickets moves at the speed of somebody else's backlog.
What. A configuration baseline before a change list. Both vendors publish one, and both have tooling that scores the current tenant against it. Start from the vendor baseline, then document every deliberate deviation with a reason. The deviations are the actual output, because they are what a future assessor or auditor will ask about.
When. Sequence by reversibility and blast radius. Legacy authentication and administrative MFA first, because they are the highest-impact and the easiest to justify. Application consent second, because it is invisible to users. Sharing defaults third, because they change day-to-day behaviour and need communication. Anything touching mail flow last, in a maintenance window, with a rollback plan.
Deliverables. A tenant baseline document, a deviation register with owners, the conditional access policy set, an app consent inventory, and a recurring review schedule for guests and external sharing. Configuration alone is not a deliverable, because tenants drift and the next administrator will not know which settings were deliberate.
Lineage. This descends from the identity work rather than the network work. It is the same argument as blast radius in cloud IAM, applied to a system where the users are everybody in the organisation. It also feeds directly into Cyber Essentials Plus, where cloud services can no longer be excluded from scope and MFA gaps are terminal.
The honest summary
Nothing here requires a new product. Almost everything is included in licences most organisations already hold, and the work is measured in configuration changes and conversations rather than deployments. What makes tenant hardening hard is that it has no natural owner: it is too operational for the security team and too security-shaped for the operations team, so it sits in the gap and drifts.
If you want a starting point that takes an afternoon, pull two reports. List every application with delegated access to mail or files, and list every sharing link that has no expiry. Almost nobody who runs those for the first time likes what comes back, and both are the sort of finding that makes the case for the rest of the programme without an argument.
If you want a tenant reviewed properly, or help running the remediation, that is the kind of work I do through Cyber Spartans.