Don’t Let Microsoft Set Your Passkey Defaults: A Hands-on Guide to Entra Passkey Profiles

By May 2026, every Entra tenant will be migrated to the new Passkey Profiles model. If you haven't opted in, Microsoft will apply its own defaults, potentially enabling synced passkeys for your entire org. This lab-proven guide shows you how to intercept the migration, configure high-assurance profiles, and leverage Microsoft Authenticator for hardware-bound security.

The March 2026 Countdown

Most Microsoft announcements are just "features." This one is a mandatory shift in architecture.

Starting in March 2026, the flat FIDO2 settings we’ve used for years are being replaced by Passkey Profiles. If you don't configure these yourself, Microsoft will auto-enable them between April and May 2026.

The Trap: If your tenant currently has "Enforce Attestation" set to No, Microsoft's migration will automatically enable Synced Passkeys for your users. For many IT Managers, allowing corporate credentials to be synced to a user's personal iCloud or Google account is a non-starter.

Understanding the New Logic

In the new "Passkey Profiles" world, we no longer have a single "On/Off" switch. We now categorize passkeys by their passkeyType:

Device-bound High Assurance Microsoft Authenticator, YubiKey, Windows Hello. Synced Convenience-focused iCloud Keychain, Google Password Manager.

The Lab Demo

For this demo, we are moving away from the "all users" default. We are going to build a High-Assurance Profile that forces the use of Microsoft Authenticator on Android or iOS.

Least Privilege & Licensing Matrix

Configure Passkey Profiles Authentication Policy Administrator (Avoid using Global Admin for daily policy tweaks). Manage Registration Campaigns Authentication Policy Administrator. This allows you to set the target to Microsoft Authenticator without broad tenant access. Conditional Access Integration Conditional Access Administrator. Required if you are locking sign-ins to specific "Phishing Resistant" strengths. Entra ID Licensing Entra ID P2 (Included in Entra Suite). P2 is required for advanced group-based profiles and the full Registration Campaign feature set.

Why Microsoft Authenticator?

Unlike a generic passkey, the Authenticator app acts as a security broker. It provides Conditional Access signals that native OS passkeys cannot:

• Device Compliance: "Is this phone jailbroken?"
• App Protection: "Is the data stay within the work profile?"
• Hardware Attestation: "Is this a real physical device or an emulator?"
• Location Compliance: "Are you authenticating from an approved location?"

The Configuration Grid

In your Entra Suite tenant, navigate to Protection > Authentication methods > Policies > Passkey (FIDO2) and create a new profile with these settings:

Passkey Type Device-bound Blocks the "syncing" of credentials to personal cloud accounts. The key stays on the phone. Enforce Attestation Yes Forces the device to prove its hardware integrity. If it's not a managed, secure chip, registration fails. Key Restrictions Allow List Explicitly whitelist Microsoft Authenticator AAGUIDs to ensure CA signals are available.

The Enrollment Experience (Demo)

When your user goes to register, they will be prompted by Android or iOS to save a passkey.

1. The Selection: The user must select Microsoft Authenticator as the provider.
2. The Attestation Check: Behind the scenes, Entra challenges the Authenticator app. Because we set Enforce Attestation to Yes, the app uses the phone’s Secure Enclave to sign the request.
3. The Result: In the Entra Sign-in logs, you will see the authentication as FIDO2 with a Device-bound status.

How to apply these in the Portal:

1. Navigate to your Passkey (FIDO2) policy.
2. Edit your Default Passkey Profile (or create a new one).
3. Under Key Restrictions, set it to Allow.
4. Click Add AAGUID, paste the strings above, and give them a clear name like "Authenticator - Android" and "Authenticator - iOS".

0:00 /0:28 1×

My Advice: If you aren't ready for a helpdesk surge, manually set your Registration Campaign to 'Disabled' or 'Enabled' (with specific targets) before April. Do not leave it on "Microsoft-managed" unless you want a surprise rollout.

📋 Microsoft Authenticator AAGUIDs

If you are enforcing Key Restrictions, you must manually "allow" the Microsoft Authenticator app by adding its unique Authenticator Attestation GUIDs (AAGUIDs). Without these, your "Allow List" will block your own users from registering.

Microsoft Authenticator (Android) de1e552d-db1d-4423-a619-566b625cdc84 Microsoft Authenticator (iOS) 90a3ccdf-635c-4729-a248-9b709135078f AAGUID

Pro-Tip : While the "Microsoft Authenticator" checkbox in the Entra portal often handles this for you, manually adding these AAGUIDs to your Passkey Profiles ensures that there is no ambiguity. It also helps you troubleshoot if a user's registration is being blocked by a restrictive policy.

Critical Warning: The Registration Campaign

Microsoft is also updating Registration Campaigns. If you have synced passkeys enabled and your campaign is set to "Microsoft-managed," Entra will start nudging users to move from SMS/Voice to Passkeys automatically.

If you're currently running a Microsoft-managed registration campaign pushing users toward Microsoft Authenticator, that campaign will suddenly start pushing them toward passkeys instead. And it will target a broader group of users.

Portal path: Authentication methods → Registration campaign

1. Navigate to Registration campaign
2. Check the current State — Microsoft-managed, Enabled, or Disabled
3. Check the Target — who is being nudged
4. If you want to keep targeting Authenticator instead of passkeys — switch from Microsoft-managed to Enabled and manually configure the target method as Microsoft Authenticator
5. If you are happy for users to be nudged toward passkeys — leave Microsoft-managed on and verify the target group is correct

If you leave this on Microsoft-managed, you lose control. After the April 2026 migration, Microsoft will start nudging users toward any passkey—including synced ones. To keep the focus on Microsoft Authenticator as your secure broker, you need to be intentional.

📢 Controlling the Nudge: Enterprise-Ready Registration Campaigns

It’s one thing to enable passkeys in the backend; it’s another to get your users to actually register them. This is where the Registration Campaign comes in.

However, there is a catch: if you leave your campaign set to Microsoft-managed, you are handing the steering wheel to Microsoft. After the March 2026 update, Microsoft will automatically shift the target of these campaigns from "Authenticator" to "Passkeys." If your tenant allows synced passkeys, your users might end up registering their corporate credentials in their personal cloud instead of the Authenticator app.

To keep your users focused on the Microsoft Authenticator broker, here are the "Enterprise-Digestible" settings I recommend:

State Enabled Avoid "Microsoft-managed." By selecting "Enabled," you retain full control over the snooze duration and the specific target method. Target Method Microsoft Authenticator By explicitly targeting the Authenticator app, you ensure users are set up for Conditional Access signals (compliance and health) rather than just a generic passkey. Days allowed to snooze 2 Days A 2-day cadence is less "noisy" than the daily default, making the registration feel like a professional request rather than an annoying pop-up. Limited number of snoozes Enabled (3-5) This gives users a grace period for busy days but ensures compliance is reached by the end of your rollout week. Enroll your CEO as last 😄

Why this matters for product owners and managers:

The Registration Campaign is your best tool to kill off "Legacy MFA" (SMS and Voice) without a forced cut-over that breaks the helpdesk. By targeting Microsoft Authenticator, you are building a foundation for Phishing Resistance.

When the user is nudged, they don't just "register a passkey"—they bind their identity to the Authenticator app on a device you can manage and trust.

Admin Tip: Use the "Excluded users and groups" feature to keep your C-suite or emergency "Break Glass" accounts out of the campaign. This prevents the CEO from being blocked by a registration prompt during a board meeting!

📱 What the User Sees: The Enrollment Journey

For this lab, we are assuming the user is being prompted by the Registration Campaign we configured in the previous step. Here is the (high level) step-by-step flow on a device.

1. The "Nudge" at Sign-In

When the user signs into a corporate app (like Outlook or Teams), they are greeted with a full-screen prompt: "Your organization requires you to set up a more secure way to sign in."

Because we targeted Microsoft Authenticator in our campaign, the button will explicitly say "Set up Passkey".

2. The Critical Handover (Same-Device Flow)

Once the user clicks "Next," the system takes over. This is the moment of truth for your governance:

• The Choice: The device will ask: "Where do you want to save your passkey?"
• The Goal: The user must select Microsoft Authenticator.

• The Troubleshooting Tip: If the user doesn't see Authenticator as an option, they likely haven't enabled it as a "Passkey Provider" in their iOS Android settings (or MDM managed):

3. The Hardware Handshake

Once Authenticator is selected:

1. The app will prompt the user to sign in (usually with their existing MFA or a Temporary Access Pass).
2. The Attestation check happens silently. The app verifies the device’s integrity via the Integrity API.
3. The user is prompted for their Device Biometrics (Fingerprint or Face Unlock). This "wraps" the private key inside the phone’s hardware security module.

4. The "Success" Proof

The user sees a final screen in the app: "Passkey added." Back in the My Security Info portal (aka.ms/mysecurityinfo), the passkey will now appear. As an admin, if you look at their profile, you will see a unique entry that lists the AAGUID we whitelisted earlier, proving that the user followed the "High-Assurance" path and didn't just save a synced key to their personal Google account.

📱 What the User Sees: The Enrollment Journey

For this lab, we are assuming the user is being prompted by the Registration Campaign we configured in the previous step. Here is the step-by-step flow on a private Android device.

1. The "Nudge" at Sign-In

When the user signs into a corporate app (like Outlook or Teams), they are greeted with a full-screen prompt: "Your organization requires you to set up a more secure way to sign in."

Because we targeted Microsoft Authenticator in our campaign, the button will explicitly say "Set up Passkey".

2. The Critical Handover (Same-Device Flow)

Once the user clicks "Next," the system takes over. This is the moment of truth for your governance:

• The Choice: Android will ask: "Where do you want to save your passkey?"
• The Goal: The user must select Microsoft Authenticator.
• The Troubleshooting Tip: If the user doesn't see Authenticator as an option, they likely haven't enabled it as a "Passkey Provider" in their Android settings.

3. The Hardware Handshake

Once Authenticator is selected:

1. The app will prompt the user to sign in (usually with their existing MFA or a Temporary Access Pass).
2. The Attestation check happens silently. The app verifies the device’s integrity via the Integrity API.
3. The user is prompted for their Device Biometrics (Fingerprint or Face Unlock). This "wraps" the private key inside the phone’s hardware security module.

4. The "Success" Proof

The user sees a final screen in the app: "Passkey added." Back in the My Security Info portal (aka.ms/mysecurityinfo), the passkey will now appear. As an admin, if you look at their profile, you will see a unique entry that lists the AAGUID we whitelisted earlier, proving that the user followed the "High-Assurance" path and didn't just save a synced key to their personal Google account.

🛠️ The "Helpdesk-Ready" Troubleshooting

"I don't see Authenticator in the list" The user needs to go to Settings > Passwords & Accounts. Under "Additional Providers," ensure Microsoft Authenticator is toggled ON. Registration fails with "Security Key not allowed" This is usually an Attestation failure. Ensure the device isn't rooted or using a 3rd party "Work Profile" wrapper that hides the hardware chip from Entra. Getting a "QR Code" on mobile device This happens when registering via a mobile browser instead of the app nudge. Advise users to open Microsoft Authenticator directly and use the "Create Passkey" option on the account tile.

Conclusion: Control the Migration, Don't Just Watch It

The automatic migration is coming whether we click "Opt-in" or not. By taking thirty minutes today to configure your Passkey Profiles and Registration Campaigns, you are choosing a Device-bound, Phishing-resistant future over a "convenient but risky" synced model.

Your Action Plan for this week:

1. Audit: Check your current Attestation setting. If it's OFF, you are currently on the "Synced" path by default.
2. Profile: Create a "Strict" Passkey Profile for your IT and High-Privilege users.
3. Target: Manually enable your Registration Campaign to target Microsoft Authenticator.

If you're running a similar setup or have questions, reach out in the comments or on LinkedIn.

— Antonio | AboutCloud

arusso@aboutcloud.io