Most organisations assume Microsoft 365 backs up their tenant configuration automatically. It doesn’t, and these anonymised stories from CoreView clients show what happens when small gaps go unchecked.
In this article
Microsoft 365 doesn’t automatically back up tenant configurations, and many IT teams lack the documentation they would need to rebuild a tenant from scratch.
Small configuration drifts now cause more damage than dramatic breaches, from misconfigured conditional access and lingering MFA exclusions to a telco with 80% of its 420,000 users lacking MFA enforcement.
Overprivileged admins are a recurring theme, including an international school with 13 global admins where Microsoft recommends no more than four, and a Copilot pilot that surfaced the CEO’s payslip within minutes.
Reducing the blast radius means fewer and less privileged admins, role-based access, centralised reporting, configuration monitoring, and named platform ownership, maintained as an ongoing discipline.
If you lost your tenant today, is your documentation good enough to restore it from the ground up?
Most clients believe Microsoft 365 automatically backs up its tenant configuration. That’s not the case, and this common misconception could be extremely costly.
My time as a consultant has taught me that many IT teams don’t document adequately, if at all. That’s nothing to do with incompetence or laziness. It’s more a testament to how complex Microsoft 365 environments can get as organisations grow.
In this post, we’re sharing some short Microsoft 365 security anecdotes from a range of CoreView clients over the years.
We see a lot more small configuration drifts than big breaches these days. Dramatic account takeovers have largely been replaced by small configuration tweaks, often made by multiple well-meaning administrators working over numerous workflows.
On their own, these minor adjustments are mostly insignificant. But collectively, they can expose sensitive SharePoint data, wipe entire device fleets, and wreak havoc on Azure workloads, costing considerable effort and resources to rectify.
Conditional access is another area where seemingly insignificant drifts can have big consequences. The rules are simple and carved in stone: grant access only when prerequisites are met.
For Australian organisations, the logical policy is to geo-lock access to Australian-owned IP addresses.
But we commonly encounter two failures:
While an exclusion could be entirely legitimate, it increases risk by bypassing MFA, which compounds over time if the exclusion never gets withdrawn.
We were working with a recently onboarded public agency in Oceania, helping them configure conditional access. When we started the contract, we discovered their baseline conditional access was minimal, and MFA wasn’t enforced at all.
What should have been a mature M365 environment was missing the bare-minimum security controls any tenant should have, let alone a large government agency.
On a side note, for CoreView to deploy into an Azure environment, our service accounts must be excluded from conditional access and MFA. CoreView offsets this risk by only allowing service accounts to deploy from our own Azure data centre.
Not everyone is enforcing MFA.
We provided an out-of-the-box MFA enforcement policy for a large telecommunications organisation. The project revealed 80% of its 420,000 users had no MFA or conditional access enforcement.
For an organisation that size, that leaves a massive number of accounts open to breaches, with unknown SharePoint access and no geographic restrictions.
It just goes to show that not all mature tenants are secure.
According to Microsoft, the absolute maximum number of global admins you should ever have per tenant is four. And that’s for the world’s largest and most complex Microsoft 365 environments.
We worked with an international school that had 13 global admins within a single tenant.
A global admin is an omnipotent deity that can do anything within a tenant, meaning they have an enormous blast radius and are a prime target for identity theft. We had 13 catastrophic breaches waiting to happen.
The school was giving global admin access by default to anyone who administered anything in that environment. It wasn’t intentional recklessness; they just didn’t understand the risk and how the system works.
We were using Microsoft Copilot to run a pilot with a small user group from a large organisation. It only took the AI a couple of minutes to start surfacing all sorts of highly sensitive material, including the CEO’s payslip and the HR wishlist of which employees to hire and fire.
Copilot wasn’t to blame. All it did was make that information easier to find. The underlying issue was the existing permissions in the Microsoft 365 governance layer.
AI tools that trivialise the effort required to unearth sensitive information underscore the importance of proper data governance.
We like to phrase a core architectural question as the ‘tenant dilemma.’ Should organisations have one tenant to rule them all? Or spread the risk over several segmented tenants?
The single tenant approach requires securing one tenant absolutely. There is no room for error. You’re building the digital equivalent of Fort Knox.
With multiple tenants, you still have several left standing should one go down. But you need to secure multiple control planes, requiring more administrative effort and a higher IT headcount. Native Microsoft permissions and tooling don’t always yield clean results.
We had one organisation running five Microsoft 365 tenants, which meant constant tenant switching. Multi-tenant segmentation can be a logical choice but isn’t particularly cost-efficient, as launching several isolated environments is expensive, even at good licensing rates.
Tenants can get messy during acquisitions. When an organisation inherits another’s tenant and security policies, aligning those environments is no easy feat.
The smaller company’s security policies usually apply during the migration phase, even though they rarely reflect the acquiring company’s position.
We had a contract with a public sector tenant serving tens of thousands of users across 20 different agencies and subdepartments.
We learned there was no way to segregate roles within them. That meant a single admin of the mega tenant could see everything and act on behalf of anyone in that entire environment.
To mitigate the risk, we switched to role-based access zones that allowed admins to operate only within their specific areas. One quick tweak made the blast radius so much smaller.
Siloed teams make everything harder because visibility becomes fragmented. Microsoft 365 is a beast to work with when each team only monitors its own workload.
We need centralised governance monitoring across all workloads, including alerting and drift detection. Correct internal structure and platform segmentation are key.
We’ve worked alongside designated platform owners with surprising technical prowess. Often, the hardest part of the job is driving accountability.
Our go-to fix is assigning a named platform owner as well as multiple active users. That tends to transform capability into accountability pretty quickly.
We’ve heard a few second-hand horror stories from other cybersec agencies over the years. Most are what we classify as data poisoning:
One thing we often see is tenant configuration records stored as portal screenshots in Word documents. If that file goes down with your tenant, you’re rebuilding the whole environment from the ground up.
We keep seeing the same themes: too many overprivileged admins, fragmented visibility, unclear ownership, and configuration drift.
Mitigation strategies include slashing admins, reducing privileges, delegating role-based access, centralising reporting, monitoring configuration changes, and consolidating onboarding/offboarding into one automated workflow.
Microsoft 365 governance isn’t a one-off set-up. The environment shifts as employees come and go, administrators adjust settings, acquisitions happen, and workloads evolve. To keep up with the complexity, organisations must continually monitor access and accountability.
Want to know which other misconceptions are leaving Microsoft 365 tenants exposed? Read CoreView’s report, Microsoft 365 Security: Common Misconceptions Among IT Leaders.
