Why Entra Passkey Policies Can Leave Admin Accounts Exposed

In this blog post Why Entra Passkey Policies Can Leave Admin Accounts Exposed we will explain why overlapping Microsoft Entra passkey profiles can quietly give administrators more sign-in options than intended, and how to close the gap without disrupting staff.

The problem is easy to miss. Your IT team may create one convenient passkey policy for employees and a stricter policy for administrators, reasonably assuming that anyone covered by both will receive the stronger protection.

That is not how Entra evaluates these profiles. If a passkey meets the requirements of any profile assigned to the user, it can be allowed. In plain English, the policies work like an “or”, not an “and”.

What Entra passkeys and profiles actually do

Microsoft Entra ID is the identity service behind Microsoft 365 and many Azure applications. It checks who a user is and helps decide what they can access.

A passkey replaces a reusable password with a protected digital credential. The user confirms their identity with a fingerprint, facial recognition, device PIN or physical security key, but the secret itself is not typed or sent to a website. This makes passkeys far more resistant to phishing.

Entra passkey profiles let organisations set different rules for different groups. A profile can control whether passkeys are synced between a person’s devices, tied to one device, or restricted to approved authenticator models.

Synced passkeys are convenient because they can follow the user through services such as a supported password manager. Device-bound passkeys remain attached to a particular device or physical security key, giving the organisation tighter control.

For most employees, synced passkeys can reduce password resets and frustrating sign-in prompts. For administrators with access to critical systems, device-bound credentials are often the safer choice.

The hidden gap created by overlapping groups

Imagine that your company creates the following profiles:

Standard employee profile
Target group: All Staff
Allowed: Synced and device-bound passkeys

Privileged administrator profile
Target group: Privileged Admins
Allowed: Approved device-bound passkeys only
Attestation: Required during registration

User: Alice
Group membership: All Staff and Privileged Admins

Expected result: Device-bound passkeys only
Actual result: Either profile can allow the passkey

Attestation is a check that helps Entra confirm the type and origin of an authenticator. It can be used to ensure administrators register an approved physical key or another trusted device-bound credential.

The configuration looks sensible when viewed profile by profile. The administrator policy is strict, documented and assigned to the correct group.

However, Alice is also covered by the standard employee profile. If her synced passkey fully satisfies that more permissive profile, Entra does not combine both profiles and apply the strictest settings. Satisfying one applicable profile can be enough.

This is the union behaviour. The available options from overlapping profiles are effectively added together rather than narrowed to the shared, strictest result.

Why this matters to business leaders

Your highest-impact accounts may have weaker controls

An attacker who compromises an ordinary employee account may gain access to email and files. An attacker who compromises a privileged administrator can potentially change security controls, create accounts, access sensitive systems or interfere with incident response.

That is why administrator protection should not depend on a broad employee policy behaving more restrictively than it actually does.

Your compliance evidence may not match reality

A policy screenshot showing “device-bound passkeys only” for administrators is not proof that every administrator is restricted to those credentials. Group overlap and the user’s effective policy also need to be examined.

This is relevant to the Essential Eight, the Australian Signals Directorate’s cybersecurity framework used as a baseline by many Australian organisations. It places strong emphasis on multi-factor authentication and restricting administrative privileges.

Passkeys can support those goals, but only when the policy design produces the intended result for real users. An auditor or customer assurance team will increasingly want evidence of the effective control, not simply evidence that a policy exists.

You can gain false confidence from a successful rollout

A smooth rollout is not always a secure rollout. If administrators can register an easier credential through a broad staff profile, support tickets may be low while the most important security requirement remains unmet.

This is similar to the issue covered in the Intune policy gap that leaves company devices exposed. A green status in an administration portal does not necessarily mean the effective control is correct.

A realistic 200-person business scenario

Consider an Australian professional services company with 200 employees, six IT administrators and several external support accounts. The business enables synced passkeys for everyone to reduce password resets and make mobile sign-in easier.

The IT team then creates a second profile requiring approved device-bound passkeys for the administrator group. They assume the more specific administrator profile overrides the general employee profile.

During a review, the company discovers that five administrators remain members of both target groups. Their synced credentials can still satisfy the employee profile, so the intended administrator restriction is not reliably achieved.

No breach is required for this to become expensive. The business must investigate existing credentials, redesign groups, retest Conditional Access and produce updated compliance evidence under time pressure.

How to close the gap without breaking sign-in

1. Map every passkey profile and target group

List each profile, what it permits and which groups receive it. Pay particular attention to broad targets such as All Users, All Staff, contractors and company-wide dynamic groups.

Then identify people who sit in more than one profile. Start with Global Administrators, Privileged Role Administrators, security administrators and accounts used by external IT providers.

2. Build mutually exclusive user groups

Avoid targeting a convenient staff profile at everyone when privileged users need different rules. Create clearly owned groups for standard users and privileged identities, with a process that prevents administrators from drifting back into the broader profile.

Group membership must be reviewed whenever someone receives or loses an administrative role. Otherwise, today’s clean design becomes next quarter’s hidden exception.

3. Enforce privileged access with Conditional Access

Conditional Access is Entra’s rule engine for deciding whether a sign-in should be allowed. Use it to require a suitable authentication strength for administrator portals, sensitive applications and privileged actions.

An authentication strength defines which sign-in methods are acceptable. For privileged access, this may include limiting passkeys to approved device-bound authenticator identifiers rather than accepting any FIDO2 passkey.

Do not assume that selecting the general “passkey” method automatically separates synced and device-bound credentials. Test the exact authenticators you expect administrators to use.

Changes should begin in report-only mode, where Entra records what would happen without blocking users. Our guide to cleaning up Conditional Access without locking out users provides a practical process for doing this safely.

4. Test people, not just policies

Select test accounts representing employees, administrators, contractors and emergency access users. Confirm which credentials each account can register and which credentials can actually open sensitive services.

Review sign-in logs after testing. This shows the authentication method used and whether the intended Conditional Access control was applied.

5. Review existing registered passkeys

Fixing group assignments does not remove the need to inspect credentials already registered to privileged users. Identify unexpected passkeys, remove credentials that no longer meet your standard and give administrators a controlled recovery process.

Emergency access accounts also require careful handling. They should not become everyday exceptions that quietly bypass the controls protecting everyone else.

The question leaders should ask their IT team

Do not ask only, “Do our administrators have a stricter passkey policy?” Ask, “Can you show me the effective passkey options for an administrator who belongs to every relevant group?”

That question moves the conversation from configuration to outcome. It also complements the checks in our guide to Conditional Access mistakes that put Microsoft 365 at serious risk.

Strong authentication needs joined-up policy design

Passkeys can reduce phishing risk, support Essential Eight goals and make sign-in easier. But a stricter profile does not automatically override a broader one when the same person is covered by both.

The safest approach combines clean group design, device-bound credentials for privileged users, carefully tested Conditional Access and regular reviews of registered authentication methods.

CloudProInc brings more than 20 years of enterprise IT experience to Microsoft Entra, Azure, Microsoft 365, Intune, Defender and wider cybersecurity projects. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we focus on practical reviews rather than handing clients a generic policy document.

If you are not sure whether your Entra passkey policies protect administrators the way your team expects, we are happy to review the effective setup and explain any gaps in plain English — no strings attached.