Cloud-only admin accounts: keeping Entra ID administration separate from on-premises AD

The risk with synchronised accounts

An account synchronised from Active Directory is managed, at least partly, from the on-premises directory. Anyone who controls that account in AD, or controls AD itself, can reset its password, change its attributes or, depending on the authentication method, sign in as that user. Granting a privileged Entra ID role to such an account extends any on-premises compromise straight into the cloud.

Microsoft's guidance is explicit: accounts holding privileged Entra ID roles should be cloud-only. The aim is that an Active Directory compromise does not automatically become a tenant compromise, and vice versa.

What a good admin account looks like

• Created directly in Entra ID, never synchronised;
• Using the .onmicrosoft.com domain or a managed domain, never a federated domain whose authentication would depend on an external identity provider;
• No mailbox and no productivity licence: no email means no phishing received on that account and no forwarding rules to watch;
• A suitable Entra ID licence only where security features require it, such as Conditional Access or PIM;
• A recognisable name, with an agreed prefix or suffix, so it stands out in logs and access reviews;
• Personal: one account per administrator, never shared, emergency accounts aside.

Protecting these accounts

A separate but weakly protected account only delivers part of the benefit. The expected controls:

1. Phishing-resistant methods: FIDO2 security keys, passkeys or Windows Hello for Business, enforced through an authentication strength in Conditional Access.
2. Just-in-time activation of roles through PIM rather than permanent assignment.
3. Dedicated Conditional Access: short sign-in frequency, compliant device or dedicated admin workstation, blocking of unexpected locations.
4. Protection from other administrators: restricted management administrative units stop less privileged roles from resetting these accounts' passwords or authentication methods.
5. Exclusive use: no general browsing, no email, no office work with that account.

Dealing with existing accounts

The migration can be done without disruption: create the cloud accounts, assign them roles as eligible, confirm they work, then remove the roles from synchronised accounts. Use the opportunity to reduce the number of privileged accounts: the exercise often reveals roles granted "just in case". Synchronised service accounts holding roles deserve special attention: in most cases they should be workload identities.

What an audit checks

• Synchronised accounts holding a privileged role, active or eligible.
• Admin accounts using a federated domain.
• Mailboxes or productivity licences on admin accounts.
• Registered authentication methods and the authentication strength required.
• Synchronisation settings regarding cloud account takeover.