CyberCQR Thinking · Identity and access
Your Secure Score doesn't count the accounts nobody remembers
Two of the best-known cloud breaches of recent years started with an account nobody was watching: a forgotten test account at Microsoft, and customer logins at Snowflake that had no second check. Small UK firms have the same accounts. There's the address used to set up Microsoft 365, an emergency login set up to old advice, a supplier who still holds the keys and a trial tenant that never closed. A security score won't show them. This briefing explains where they come from, why they matter and the questions a board should ask.
Summary
The point for boards. Most firms protect the accounts people use every day. Attackers look for the ones nobody uses: set-up, emergency, test, supplier and app accounts. Each holds power, few have an owner, and many sit outside the controls the rest of the firm relies on. Your IT provider or an adviser can find and fix them, but the accountability for knowing they exist stays with the firm's directors or partners.
What went wrong at Microsoft and Snowflake?
In late November 2023, a Russian state-backed group known as Midnight Blizzard tried common passwords against a small number of Microsoft logins. One of them was a legacy, non-production test tenant account. It did not have multi-factor authentication (MFA) switched on, so a guessed password was enough [1] [2]. From there the group found an old test app with elevated access to Microsoft's corporate environment. It used that app to read mailboxes belonging to senior leaders [2]. Microsoft said that if the same team built the tenant today, its own rules would force MFA on from the start [2].
In 2024, criminals signed in to Snowflake customer accounts using passwords stolen by malware, some taken years earlier. Snowflake's own systems were not breached. The affected customer accounts had no MFA and no limit on where sign-ins could come from. Mandiant, which investigated, said about 165 organisations were notified [3].
Neither attack needed a new weakness. Both used an account that nobody had looked at for a long time.
Where do these accounts come from in a small firm?
None of them is unusual. Most are created for a good reason, then left alone once the job is done.
1. The set-up account on onmicrosoft.com
When anyone signs up for Microsoft 365, Microsoft creates a tenant and makes that first account a Global Administrator [5]. Its address ends in onmicrosoft.com, because the firm's own domain isn't connected yet. A reseller, an old IT provider or whoever originally set up IT often made it. Years later it may still hold full control, protected by a password that sits in a spreadsheet or in someone's head.
2. Break glass missing, or built to old advice
An emergency access account, often called break glass, lets the firm back in if normal sign-in fails. For years the common advice was to exclude it from MFA and give it a long password. Since October 2024 Microsoft has required MFA for everyone signing in to its admin portals, emergency accounts included [7]. An account built the old way may not work on the day it is needed. Some firms never set one up at all. Others tied it to one person's mobile number.
3. Suppliers who still hold the keys
Microsoft partners used to receive standing Global Administrator rights over their customers' tenants. Microsoft has replaced that with granular access, limited in role and time, which the client approves [10]. Many firms have never checked which partners are listed, or whether a provider they left still appears. The same goes for named admin accounts created for contractors.
4. Second tenants and subscriptions
Trials, test tenants and cloud subscriptions are quick to start and easy to forget. Some are owned by a set-up account or a personal email address that sits outside the firm's sign-in rules. Microsoft's own breach began in one [1]. Attackers also reuse abandoned tenants. In 2023, Midnight Blizzard renamed compromised small business tenants, added onmicrosoft.com names such as "teamsprotection" and used them to send Teams messages posing as technical support [4]. A forgotten tenant can become someone else's tool.
5. Exemptions that became permanent
Senior staff, service accounts and shared mailboxes are often excused from MFA "for now". Our case study Simpler and stronger describes a finance firm whose leadership team had been exempt for years. Every exemption is an account that a guessed or stolen password can open.
6. Apps and AI agents with access
Every app linked to Microsoft 365 is granted permissions. By default, staff can let an app reach their own mailbox and files; an administrator can grant access across the whole firm [11]. AI note-takers, assistants and agents are apps too. The Microsoft breach moved from a test account to senior mailboxes through exactly this kind of permission [2]. Our infographic Could your AI be turned on you? covers what those tools can do once connected.
Why doesn't Secure Score show this?
Microsoft Secure Score is useful. It lists recommended settings and awards points as they are put in place. Three limits matter for a board.
- It counts settings, not owners. It can tell you MFA is required for administrator roles. It cannot show who owns the set-up account, why a supplier still has access or whether anyone remembers the trial tenant.
- Some points can be self-declared. An action marked as resolved, whether "through third party" or "through alternate mitigation", earns its points. Microsoft says it has no visibility of whether that control is really in place [8].
- It only sees the tenant it is in. A second tenant, an old subscription or another cloud service has its own settings, or none.
So a rising score can sit alongside a forgotten Global Administrator. That is the same gap we describe in All green, still exposed: a report built on the known estate says nothing about the unknown.
How this fits with Zero Trust and defence in depth
Zero Trust means no account, device or network is trusted just because it is "inside". The National Cyber Security Centre (NCSC) puts two principles first: know your architecture, then your user, service and device identities [12]. A firm that cannot list its admin, emergency, supplier and app accounts has not started, whatever products it owns. Our article Understanding Zero Trust and white paper The VPN Trap explain the wider model.
Defence in depth is the other half. No single control holds every time, so each layer should catch what the one before it misses. Forgotten accounts are dangerous because they skip several layers at once.
| Layer | What it does | What a forgotten account skips | Read more |
|---|---|---|---|
| Know every account | Gives each one an owner, a reason and a review date | Nobody knows it exists | Temporary and test accounts |
| Strong sign-in | MFA for everyone; phishing-resistant methods for admins | Often exempt, or set up before MFA was required | Identity: ten must-do actions |
| Least privilege | Admin rights only when needed, for a set time | Usually holds standing Global Administrator rights | Just-in-time privileged access |
| Access conditions | Checks device, location and risk before letting anyone in | Often excluded from the policies, or in another tenant | Securing the new perimeter |
| Detection | Alerts on unusual sign-ins and changes | Rarely signs in, so nobody has a baseline for it | All green, still exposed |
| Recovery | A tested way back in when sign-in fails | Break glass missing, or built to old advice | The evolution of authentication, section 15.3 |
Table 1. CyberCQR's summary. Each layer is described in the linked paper.
Where Cyber Essentials comes in
Since April 2026, Cyber Essentials fails any firm with MFA available on a cloud service but switched off, and every such service is in scope [13] [14]. One forgotten admin account without MFA is now enough. Our briefing Cyber Essentials since April 2026 covers the changes in full. The certificate and this work support each other: the assessor checks the baseline once a year; owning your accounts keeps it true in between.
What good looks like
- Every admin, emergency, supplier, test and app account is listed, with a named owner, a reason to exist and a review date.
- There are fewer than five Global Administrators [5], and none of them is used for email or browsing.
- Two emergency accounts exist, cloud-only, protected by security keys rather than a password alone, with an alert on every sign-in and a test at least every 90 days [6].
- No supplier holds standing Global Administrator rights. Partner access is limited to the roles and time it needs [10].
- No one is exempt from MFA. Where Conditional Access isn't licensed, security defaults are switched on [9].
- Staff cannot grant new apps access to company data without review [11].
- Old tenants and subscriptions are closed, or brought under the same rules as the main one.
What we see in practice
At a UK finance firm of under 1,000 staff, we stepped in as acting chief information security officer after spear phishing aimed at the leadership. The senior team had been excused from MFA and basic account controls for years. Admin passwords were kept in a weakly encrypted document on a file share. The service desk knew directors' passwords, and one executive's assistant held their sign-in details.
None of this showed up as a single failing setting. Each account had an owner on paper and a reason someone had once accepted. Within about 90 days, privileged access shifted to just-in-time roles, secrets went into a vault and everyone, the board included, signed in with MFA. The full story is in Simpler and stronger. The lesson for this briefing: the riskiest accounts are rarely the busy ones. They are the ones that were set up once and then treated as part of the furniture.
Five questions for your next board meeting
- Who are our Global Administrators? How many are there, who owns each one, and is the original set-up account among them?
- Could we get back in tomorrow? Do we have two tested emergency accounts, and when were they last used in a drill?
- Which suppliers can change our tenant? What roles do they hold, for how long, and who approved it?
- Who is exempt? Which accounts are excused from MFA or access policies, and why?
- What else do we own? Are there other tenants, trials or subscriptions in our name, and who looks after them?
Conclusion
A security score measures how well the firm has configured the tenant it can see. Attackers go looking for the accounts it cannot. Finding them needs no new product: a list, an owner for each account and a decision to close or protect it. Our Top 10 actions turn this into a checklist the board can track, and the good practice guide gives your IT lead or provider the steps.
Glossary
| Term | Meaning |
|---|---|
| Break glass account | An emergency administrator account kept for when normal sign-in fails. Also called an emergency access account. |
| Conditional Access | Microsoft's rules that decide whether a sign-in is allowed, based on the user, device, location and risk. Needs Entra ID P1 or higher. |
| Defence in depth | Using several layers of protection, so that if one fails another can still stop or catch an attack. |
| Global Administrator | The most powerful role in Microsoft 365 and Entra ID. It can change every setting and every account. |
| Granular delegated admin privileges (GDAP) | The way Microsoft partners now get limited, time-bound admin access to a customer's tenant, approved by the customer. |
| Multi-factor authentication (MFA) | Signing in with something beyond a password, such as an app prompt or a security key. |
| onmicrosoft.com | The address Microsoft gives every new tenant before the firm's own domain is added. Accounts on it often outlive the set-up work. |
| Phishing-resistant MFA | Sign-in methods, such as security keys and passkeys, that a fake website cannot capture and replay. |
| Secure Score | Microsoft's measure of how many of its recommended security settings a tenant has in place. |
| Security defaults | A free Microsoft setting that requires MFA and blocks older sign-in methods, for tenants without Conditional Access. |
| Tenant | A firm's own instance of Microsoft 365 and Entra ID, holding its users, settings and data. |
| Zero Trust | A security model in which no user, device or network is trusted by default; every request is checked. |
Table 2. Terms used on this page (alphabetical).
Further reading
From CyberCQR
- Cloud accounts nobody owns: ten actions for boards
- Finding and securing forgotten cloud accounts: a good practice guide
- Cyber Essentials since April 2026: the cloud accounts that fail you
- Simpler and stronger: fixing sign-in from the boardroom down
- More tools, less security
- Document library: every paper and tool
External
- Microsoft: Manage emergency access admin accounts [6]
- NCSC: Zero trust architecture design principles [12]
References
- [1]Microsoft Security Response Center, Microsoft actions following attack by nation state actor Midnight Blizzard, 19 January 2024.
https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/ - [2]Microsoft Threat Intelligence, Midnight Blizzard: Guidance for responders on nation-state attack, 25 January 2024.
https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ - [3]Mandiant (Google Cloud), UNC5537 targets Snowflake customer instances for data theft and extortion, 10 June 2024.
https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion - [4]Microsoft Threat Intelligence, Midnight Blizzard conducts targeted social engineering over Microsoft Teams, 2 August 2023.
https://www.microsoft.com/en-us/security/blog/2023/08/02/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/ - [5]Microsoft Learn, Best practices for Microsoft Entra roles, viewed 7 November 2026.
https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices - [6]Microsoft Learn, Manage emergency access admin accounts in Microsoft Entra ID, viewed 7 November 2026.
https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access - [7]Microsoft Learn, Planning for mandatory multifactor authentication for Azure and other admin portals, viewed 7 November 2026.
https://learn.microsoft.com/entra/identity/authentication/concept-mandatory-multifactor-authentication - [8]Microsoft Learn, Assess your security posture with Microsoft Secure Score, viewed 7 November 2026.
https://learn.microsoft.com/defender-xdr/microsoft-secure-score-improvement-actions - [9]Microsoft Learn, Security defaults in Microsoft Entra ID, viewed 7 November 2026.
https://learn.microsoft.com/entra/fundamentals/security-defaults - [10]Microsoft Learn, Introduction to granular delegated admin privileges (GDAP), viewed 7 November 2026.
https://learn.microsoft.com/partner-center/customers/gdap-introduction - [11]Microsoft Learn, User and admin consent in Microsoft Entra ID, viewed 7 November 2026.
https://learn.microsoft.com/entra/identity/enterprise-apps/user-admin-consent-overview - [12]National Cyber Security Centre, Zero trust architecture design principles, viewed 7 November 2026.
https://www.ncsc.gov.uk/collection/zero-trust-architecture - [13]National Cyber Security Centre, Cyber Essentials: requirements for IT infrastructure, v3.3, April 2026.
https://www.ncsc.gov.uk/sites/default/files/2026-08/IT%20Requirements%20v3.3.pdf - [14]IASME, Upcoming changes to the Cyber Essentials scheme: April 2026 update, 3 November 2025.
https://iasme.co.uk/articles/upcoming-changes-to-the-cyber-essentials-scheme-april-2026-update/ - [15]Department for Science, Innovation and Technology and Home Office, Cyber security breaches survey 2025/2026, 30 April 2026.
https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026
Security is the outcome, not a solution.
CyberCQR is a UK cyber security advisory practice. We help firms find the cloud accounts nobody owns, protect the ones they need and close the rest, using the Microsoft licences they already pay for, without vendor commissions or product resale.