Cloud accounts nobody owns: ten actions for boards

1. Name one director or partner who owns privileged and cloud accounts

Why it matters. Admin accounts sit between IT, suppliers and whoever set up Microsoft 365. When nobody owns the list, nobody notices when it grows.

What to do.

• Name one senior person who reports on actions 2 to 10 at least twice a year.
• Add a plain-words risk to the register: "an admin, supplier or forgotten account used to take control of our Microsoft 365".
• Agree that providers do the work but the owner and the board keep the accountability.

2. List every account with admin rights, and every account nobody signs in to

Why it matters. You cannot protect an account you have not found. The NCSC puts knowing your identities near the top of its Zero Trust principles [8].

What to do.

• Export everyone holding an admin role, including roles assigned through groups.
• Export accounts with no sign-in for 90 days or more, and decide for each: keep, disable or delete.
• Record an owner, a reason and a review date against every account you keep.

Our temporary and test account strategy sets out how short-lived accounts should be created and removed.

3. Find the set-up account and any other tenants in your name

Why it matters. The account that created your Microsoft 365 is made a Global Administrator automatically [2]. It often uses an onmicrosoft.com address and a password set years ago. Old trial tenants and subscriptions may still exist, and attackers have reused small business tenants to send convincing Teams messages [7].

What to do.

• Find the first account created in the tenant and confirm who holds its password today.
• Ask your IT provider and finance team for every Microsoft tenant, trial and Azure subscription paid for or signed up to in the firm's name.
• Close what you no longer need. Bring the rest under the same sign-in rules as the main tenant.

4. Cut Global Administrators to fewer than five

Why it matters. Global Administrator can change every setting and every account. Each extra holder is another password an attacker can target.

What to do.

• Move day-to-day work to narrower roles, such as User Administrator or Exchange Administrator [2].
• Give admins a separate account for admin work, not the one they use for email and browsing.
• Where licensed, make roles eligible rather than permanent, so rights are requested when needed and expire. See Just-in-time privileged access.

5. Two emergency accounts, built to current advice and tested

Why it matters. If sign-in breaks, the firm needs a way back in. Accounts excluded from MFA under older advice may now fail on the day they are needed [4].

What to do.

• Keep at least two cloud-only emergency accounts on the onmicrosoft.com domain, not synchronised from an office server [3].
• Protect them with FIDO2 security keys stored in separate secure places, using a different method from everyday admin accounts.
• Exclude them from access policies that could block sign-in, but never from MFA.
• Alert on every sign-in and test them at least every 90 days, and after staff changes [3].

6. MFA for every account, phishing-resistant for admins, no exemptions

Why it matters. Both the Microsoft and Snowflake breaches began with accounts that had no MFA [1] [11]. Exemptions for senior staff or service accounts are where it is missing most often.

What to do.

• If you have no Conditional Access, switch on security defaults. It is free and requires MFA for everyone [5].
• Move admins first to security keys or passkeys, which a fake sign-in page cannot capture.
• List every exemption, with an owner and an end date. Our case study Simpler and stronger shows a senior team giving theirs up.

7. Limit supplier access to the roles and time they need

Why it matters. An IT provider with standing Global Administrator rights over many customers is a single point of failure for all of them. Microsoft's granular delegated admin privileges (GDAP) limit partner access by role and time, with the customer's approval [6].

What to do.

• Check the partner relationships listed in your Microsoft 365 admin centre. Remove any provider you no longer use.
• Ask current providers which roles they hold, for how long, and who on their side can use them.
• Write least privilege, MFA and notice of changes into the contract. See Third-party and supply chain ransomware.

8. Control which apps and AI tools can reach company data

Why it matters. By default, staff can let apps reach their own mail and files [12]. AI note-takers and agents count too. At Microsoft, an old app with wide permissions turned one weak account into access to senior mailboxes [1].

What to do.

• Restrict user consent to verified publishers and low-risk permissions, or switch it off, and turn on the admin approval workflow [12].
• Review apps that already hold permissions across the firm, and remove those nobody can explain.
• Include AI agents in the same review. See Could your AI be turned on you?

9. Alert on the accounts that should be quiet

Why it matters. A set-up or emergency account that suddenly signs in is either a drill or an attack. Busy accounts generate noise; quiet ones should never surprise you.

What to do.

• Alert on every sign-in by emergency, set-up and supplier accounts, and on any new Global Administrator.
• Block older sign-in methods that cannot do MFA [5].
• Make sure someone reads the alerts out of hours, whether in-house or a provider.

10. Use Secure Score as an input, not the answer

Why it matters. Secure Score measures settings in one tenant. Points marked "resolved through third party" or "alternate mitigation" are self-declared, and Microsoft cannot see whether they are true [13].

What to do.

• Record why any action is marked resolved or risk accepted, and who decided.
• Report the account list from action 2 alongside the score, so the board sees both.
• Review twice a year, and after any change of IT provider. See All green, still exposed.