It happens more often than anyone admits. A Microsoft 365 tenant gets created for testing: a trial, a proof of concept, a quick evaluation. Then it works well enough that it becomes the production tenant. Users get onboarded, licences assigned, data accumulates. Nobody goes back to apply the security controls a production tenant should have had from day one.
We recently cleaned up exactly this situation. The tenant had been running as the primary business environment for over two years, carrying the security posture of a test lab.
What We Found
Eleven Global Admins. Microsoft recommends two to four. Eleven is a sign that admin access was handed out during the test phase whenever someone needed to configure something, and nobody revoked it. Some were user accounts in different roles. Others were duplicates: the same person with both a user@company.com and a user@company.onmicrosoft.com account, each with Global Admin.
Duplicate identities. Several users had accounts on both the custom domain and the .onmicrosoft.com domain. During the test phase, accounts were created on the default domain. When the custom domain was added, some users got new accounts while their old ones persisted. Both had different role assignments, different MFA, different licences. Not just a security risk. It wastes licences and makes it impossible to get a clean picture of who has access to what.
Legacy per-user MFA. The old model from the Users blade, predating Conditional Access. No flexibility (all or nothing per user), no risk-based enforcement, conflicts with Conditional Access if you add it later. The migration path is clear (move to Conditional Access), but the sequencing matters.
The Fix
The cleanup had to happen in a specific order. Getting it wrong risks locking out administrators or creating a window with no MFA enforcement.
1. Break-glass account first. Cloud-only, excluded from all Conditional Access policies, password stored physically (not in a password manager that might be affected by the outage you need it for), monitored with alerts on sign-in. Do not skip this. We've seen organisations lock themselves out of their own tenant.
2. Conditional Access policies. Replace per-user MFA with proper policies: require MFA for all users (exclude break-glass), block legacy authentication, require compliant devices for sensitive apps if Intune is in use. Deploy in report-only mode for two weeks first. Review the "What If" results before switching to enforcing.
3. Disable per-user MFA. Only after Conditional Access is actively enforcing. If you disable per-user MFA before CA is live, there's a window with no MFA at all.
4. Clean up roles and duplicates. Downgrade Global Admins to least-privilege roles (most only need User Administrator, Exchange Administrator, or similar). Delete duplicate accounts after migrating licences and roles to the primary.
The Result
| Item | Before | After |
|---|---|---|
| Global Admin accounts | 11 | 3 (2 named admins + break-glass) |
| Duplicate user accounts | 8 pairs | 0 |
| MFA enforcement | Per-user (legacy) | Conditional Access |
| Break-glass account | None | 1, monitored |
| Legacy auth | Allowed | Blocked |
About a day of active work spread over two weeks (for the CA report-only monitoring period).
Check Your Secure Score
Once the identity cleanup is done, check your Microsoft Secure Score in the Defender portal. Test tenants that became production almost always have a dismal score: storage accounts wide open to the internet, SQL servers with public endpoints, public IPs on VMs that don't warrant them, and missing Defender security extensions, to name a few we see all the time.
Secure Score won't catch everything, but it gives you a prioritised list of the most impactful changes. For a tenant that's been running as a test environment for two years, expect the score to be uncomfortably low. That's normal. It just means nobody applied the production baseline.
The Lesson
Test environments becoming production is a reality. The mistake isn't letting it happen. Sometimes it's the right decision. The mistake is not going back to apply production-grade security afterwards.
If your M365 tenant started as a test, a trial, or a quick setup, the issues accumulate silently and none of them announce themselves until something goes wrong.
Not sure if your M365 tenant has inherited test-phase security debt? Get in touch. We run identity and access reviews that surface these issues before they become incidents.