Finding and securing forgotten cloud accounts: a good practice guide

Summary

The board-level case is in our briefing Your Secure Score doesn't count the accounts nobody remembers. This guide is the technical companion.

1. What licence do you have?

Some controls depend on the licence. Check what you hold before you plan, because it decides which tools you can use for sign-in rules and admin rights.

Table 1. Summary for planning; confirm against your own licence before relying on it. Longer history needs logs sent to Azure Monitor or another store.

2. Before you change anything: emergency access

Do this first. Every later step touches admin rights or sign-in rules, and a mistake there can lock out every administrator. Microsoft's current guidance is clear [3]:

1. Create two accounts. Cloud-only, on the tenant's onmicrosoft.com domain, not synchronised from an office server and not federated. Give each a name that does not reveal its purpose.
2. Assign Global Administrator permanently. If you use Privileged Identity Management, make these two assignments active, not eligible.
3. Register phishing-resistant sign-in. FIDO2 security keys are Microsoft's recommended method. Use a different method from your everyday admins, so one failure cannot affect both. Register at least two keys per account.
4. Store keys apart. Keep the keys and any PIN in secure places in separate locations, not tied to one person or phone.
5. Exclude them from blocking policies, not from MFA. In Conditional Access, put both accounts in a group excluded from policies that could block sign-in, such as device or location rules. Since Microsoft's mandatory MFA enforcement began in October 2024, these accounts must use MFA for admin portals anyway [4].
6. Alert on every use. See section 9.
7. Test. Sign in with each account and perform an admin task at least every 90 days, and after staff or licence changes. Record the result [3].

Our white paper The evolution of authentication (section 15.3) explains why the older advice to exclude these accounts from MFA no longer holds.

3. Find every privileged account

Start with Global Administrator, then the other high-impact roles. Microsoft recommends keeping that role to fewer than five people, and under ten privileged role assignments overall [2].

In the admin centre

Open the Microsoft Entra admin centre, then Entra ID, Roles & admins and Global Administrator. Repeat for the other high-impact roles:

• Privileged Role Administrator
• Privileged Authentication Administrator
• Security Administrator
• Exchange Administrator and SharePoint Administrator
• User Administrator

Where you use Privileged Identity Management, check eligible as well as active assignments.

With Microsoft Graph PowerShell

For a repeatable record, an administrator can run the following. It returns active members of the Global Administrator role; eligible assignments in Privileged Identity Management need a separate query.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"
$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id |
  ForEach-Object { $_.AdditionalProperties.userPrincipalName }

For each account found, record

• A named owner: a person, not "IT" or the provider's name.
• Why it needs this role, and whether a narrower role would do.
• Whether it is also used for email or browsing. Cyber Essentials expects accounts with admin rights to be separate and kept for that work alone [10].
• Its sign-in method, and whether it is phishing-resistant.
• A review date.

4. Find set-up, stale and test accounts

The set-up account

When a tenant is created, the account that signed up becomes a Global Administrator [2]. Its address usually finishes in onmicrosoft.com. Sort users by creation date to find the first one, and list every other user on that domain. For each, decide: convert it into one of the two emergency accounts, give it a named owner and normal controls, or delete it.

Stale accounts

Export users with the date each one last signed in. In the admin centre, open Entra ID, then Users, and add that column. In PowerShell, this activity data needs Entra ID P1 or higher:

Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"
$cutoff = (Get-Date).AddDays(-90)
Get-MgUser -All -Property DisplayName,UserPrincipalName,AccountEnabled,SignInActivity |
  Where-Object { -not $_.SignInActivity.LastSignInDateTime -or
                 $_.SignInActivity.LastSignInDateTime -lt $cutoff } |
  Select-Object DisplayName,UserPrincipalName,AccountEnabled

Disable first, wait a set period, then delete. Shared mailboxes and service accounts need the same review: each should have an owner and should not allow interactive sign-in unless it must.

Test and temporary accounts

Our temporary and test account strategy sets out naming, expiry and removal rules. Microsoft's own breach began with a legacy test account that had no MFA [1].

5. Other tenants and subscriptions

A firm can own more than one Microsoft tenant without realising it: an early trial, a test tenant, a tenant created by a developer or an old provider, or an Azure subscription signed up with a personal or onmicrosoft.com account.

• Ask finance for every Microsoft invoice and card payment, and match each to a tenant.
• In the Azure portal, check Subscriptions and the account that owns each one. Make sure ownership sits with a named account under your normal sign-in rules.
• For each extra tenant: close it, or apply the same controls as the main one, including emergency access and security defaults or Conditional Access.

Abandoned tenants are useful to attackers. In 2023 Microsoft reported a state-backed group renaming compromised small business tenants and adding onmicrosoft.com names that looked like technical support, then using them to send Teams phishing messages [7].

6. Partner and supplier access

Microsoft has moved partners from blanket rights over customer tenants to granular delegated admin privileges (GDAP): named roles, for a set time, approved by the customer [6].

1. Microsoft 365 admin centre, Settings, Partner relationships. List every partner and the roles each holds.
2. Remove any partner you no longer work with.
3. For current partners, agree the least set of roles and the shortest duration that lets them do their job. Global Administrator should be the exception.
4. Check for guest or named accounts created for contractors. These need an owner and an end date like any other account.
5. Write MFA, least privilege, notice of changes and removal on exit into the contract. Our paper Third-party and supply chain ransomware covers supplier terms more widely.

7. Sign-in rules and exemptions

Without Conditional Access

Turn on security defaults: Entra ID, Overview, Properties, Manage security defaults. It makes all users enrol in MFA, enforces MFA for administrators, blocks older sign-in methods and protects admin activity such as the Azure portal [5]. Microsoft advises revoking existing sessions when you switch it on, so everyone sets up MFA.

With Conditional Access

Build at least: MFA for all users; phishing-resistant MFA for admin roles; block older sign-in methods; MFA for Azure management. Run new policies in report-only mode first, then switch them on. Exclude only the emergency access group from policies that could stop anyone signing in.

Exemptions

List every account or group excluded from any sign-in policy. For each, record who approved it, why and when it ends. Senior staff exemptions are the most common and the most targeted; our case study Simpler and stronger shows how one firm removed them in about 90 days.

8. App and AI access

By default, users can let an app access their own data for permissions that do not need an administrator. Administrators can grant an app access across the whole tenant [11].

1. Under Entra ID, Enterprise apps, open the consent settings for users. Allow staff approval only for verified publishers and low-risk permissions, or switch it off entirely.
2. Turn on the admin consent workflow, so staff can request an app and an administrator reviews it.
3. Under Enterprise apps, review apps with permissions granted for the whole organisation. Remove any nobody can explain, and record an owner for the rest.
4. Treat AI assistants, note-takers and agents as apps. Our infographic Could your AI be turned on you? and case study Automation without blind trust cover what an agent should and should not be allowed to do.

9. Alerts for the accounts that should be quiet

Emergency, set-up and supplier accounts are rarely used. That makes any use worth a look. Microsoft's guidance is to send Entra sign-in logs to Azure Monitor and raise a critical alert whenever an emergency account signs in [3]. A query of this form, with your accounts' object IDs, does the job:

SigninLogs
| where UserId in ("<object-id-1>", "<object-id-2>")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, ResultDescription

Also alert on: a new Global Administrator; a new partner relationship; a change to security defaults or a Conditional Access policy; and a new app granted permissions across the organisation. Without Azure Monitor, your IT provider's monitoring service should cover the same events. Ask them to show you one firing in a test.

10. Reading Secure Score honestly

Secure Score lists recommended actions and gives points as they are completed. Some points are confirmed from Microsoft's own data. Others depend on status you set: the two "resolved" options, through a third party or through alternate mitigation, both earn points, and Microsoft says it cannot see whether those controls are fully in place [13].

• Every manual status should have a note: what covers the control, who decided and when it will be reviewed.
• "Risk accepted" earns no points. It is the honest status where a control is deliberately not used, and the decision belongs to the business owner, not the provider.
• Report the score alongside the account list from sections 3 to 6, so the board sees what the score cannot. Our briefing All green, still exposed explains why.

11. How this maps to Cyber Essentials and Zero Trust

The same work supports both. Cyber Essentials sets a baseline that is assessed once a year. The NCSC's Zero Trust principles describe the target model [8]. Defence in depth means each control should still leave another in place if it fails.

Table 2. CyberCQR's mapping. Cyber Essentials areas are summarised from the v3.3 requirements [10]; check the question set your certification body uses. For the Cyber Essentials side in full, see Cyber Essentials since April 2026: ten actions before renewal.

12. Checklist and indicators for the board

• Two emergency accounts, with security keys, alerted and tested in the last 90 days
• Fewer than five Global Administrators, each with a named owner
• Set-up account found and converted, controlled or deleted
• No account unused for 90 days without a recorded reason
• Every tenant and subscription in the firm's name listed and controlled
• Partner relationships reviewed; no standing Global Administrator for suppliers
• MFA for everyone; phishing-resistant for admins; every exemption with an end date
• User consent restricted; organisation-wide app permissions reviewed
• Alerts on quiet accounts, admin changes and new app permissions
• Every manual Secure Score status explained

Suggested indicators for the twice-yearly report: number of Global Administrators; days since the last emergency access test; number of MFA exemptions and the oldest one; accounts unused for 90 days; partners with admin roles. These are CyberCQR's suggestions, not benchmarks.

Glossary

Table 3. Terms used on this page (alphabetical).

Further reading

From CyberCQR

• Your Secure Score doesn't count the accounts nobody remembers
• Cloud accounts nobody owns: ten actions for boards
• Just-in-Time Privileged Access Strategy
• Securing the New Perimeter: Modern Identity Security
• Cyber Essentials since April 2026: the cloud accounts that fail you
• Document library: every paper and tool

External

• Microsoft: Manage emergency access admin accounts [3]
• NCSC: Zero trust architecture design principles [8]

References

1. [1]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/
2. [2]Microsoft Learn, Best practices for Microsoft Entra roles, viewed 7 November 2026.
   https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
3. [3]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
4. [4]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
5. [5]Microsoft Learn, Security defaults in Microsoft Entra ID, viewed 7 November 2026.
   https://learn.microsoft.com/entra/fundamentals/security-defaults
6. [6]Microsoft Learn, Introduction to granular delegated admin privileges (GDAP), viewed 7 November 2026.
   https://learn.microsoft.com/partner-center/customers/gdap-introduction
7. [7]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/
8. [8]National Cyber Security Centre, Zero trust architecture design principles, viewed 7 November 2026.
   https://www.ncsc.gov.uk/collection/zero-trust-architecture
9. [9]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/
10. [10]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
11. [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. [12]Microsoft Learn, Microsoft Entra data retention, viewed 7 November 2026.
    https://learn.microsoft.com/entra/identity/monitoring-health/reference-reports-data-retention
13. [13]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