Listen to this Post
Introduction:
The transition to passwordless authentication with passkeys represents a monumental shift in enterprise security. However, as highlighted by Microsoft MVP Nathan McNulty, seamless integration with existing Mobile Device Management (MDM) compliance and App Protection Policies (APP) presents significant operational challenges. This guide delves into the technical configurations and compensating controls necessary to deploy passkeys effectively without compromising security posture.
Learning Objectives:
- Understand the technical conflict between passkey registration and strict MDM/APP conditional access policies.
- Learn how to implement and verify compensating security controls, including mandatory Multi-Factor Authentication (MFA).
- Master the PowerShell and Entra ID commands required to configure a phased, secure passkey rollout.
You Should Know:
- The Core Conflict: Device Registration vs. Conditional Access
The primary technical hurdle is that the passkey registration process often cannot simultaneously satisfy a Conditional Access policy that requires a device to be already compliant. The device attempts to register a passkey before it has proven its compliance status to the entitlement system, creating a catch-22 scenario.
` Check Conditional Access policies targeting device state`
`Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.Conditions.Devices.State -eq “requireCompliantDevice”} | Format-List DisplayName, State, Conditions`
Step-by-step guide:
This PowerShell command (using the Microsoft Graph `Mg` module) lists all Conditional Access policies that mandate a device to be compliant. Identifying these policies is the first step in understanding what might be blocking passkey registration flows for your users.
2. Implementing a Compensating Control: Require MFA Always
As Nathan McNulty suggests, a foundational compensating control is to enforce MFA unconditionally. This ensures that even if a device is not yet compliant, an additional layer of authentication protects the registration process and subsequent access.
` Create a new Conditional Access policy to require MFA for all users, all cloud apps, from any device state.`
`$params = @{`
` displayName = “ALWAYS REQUIRE MFA – Compensating Control”`
` state = “enabled”`
` conditions = @{`
` applications = @{`
` includeApplications = “All”`
` }`
` users = @{`
` includeUsers = “All”`
` }`
` devices = @{`
` deviceFilter = @{`
` mode = “exclude”`
` rule = “device.trustType -eq \”ServerAD\” -or device.trustType -eq \”AzureAD\””`
` }`
` }`
` }`
` grantControls = @{`
` operator = “OR”`
` builtInControls = @(`
` “mfa”`
` )`
` }`
`}`
`New-MgIdentityConditionalAccessPolicy -BodyParameter $params`
Step-by-step guide:
This script creates a new CA policy named “ALWAYS REQUIRE MFA”. It applies to `All` users and `All` cloud applications. The `deviceFilter` excludes hybrid and Azure AD joined devices (often managed via other means), focusing the MFA requirement on personal or unmanaged devices. The `grantControls` block mandates MFA ("mfa") as the only control to grant access.
3. Auditing User Risk with Identity Protection
Leverage Azure AD Identity Protection to add a layer of risk-based conditioning alongside your MFA requirement, ensuring that high-risk sign-ins are blocked outright, regardless of passkey registration attempts.
` Check and enable riskyUsers policies via Microsoft Graph`
`Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.Conditions.UserRiskLevels -ne $null} | FL DisplayName, Conditions.UserRiskLevels`
` Enable the user risk policy in Azure AD Identity Protection (UI recommended for initial setup)`
` Navigate to: Azure Portal > Azure AD > Security > Identity Protection > User risk policy`
Step-by-step guide:
While policies are often configured via the GUI for safety, you can audit existing user risk policies with PowerShell. The user risk policy should be configured to require a password change or block access on `High` risk. This works in concert with your base MFA policy.
4. Configuring App Protection Policies (APP) for Authenticator
To ensure the Microsoft Authenticator app, where passkeys are stored, is itself protected, configure an App Protection Policy. This safeguards the passkeys even on devices that are not fully MDM-enrolled.
` Intune Graph API call to list existing APP policies (example structure)`
`GET https://graph.microsoft.com/v1.0/deviceAppManagement/managedAppPolicies`
` Key settings for a policy protecting Authenticator:</h2>
<h2 style="color: yellow;"> – Required: Pin for access</h2>
` - Block managed apps from running on jailbroken or rooted devices`
<h2 style="color: yellow;"> – Encrypt app data</h2>
<h2 style="color: yellow;"> – Prevent corporate data backups`
<h2 style="color: yellow;">
` - Block managed apps from running on jailbroken or rooted devices`
<h2 style="color: yellow;">
<h2 style="color: yellow;">
Step-by-step guide:
In the Microsoft Intune admin center, create a new App Protection Policy. Target the policy to `Microsoft Authenticator` on `iOS` and `Android` platforms. Under Access requirements, set a PIN to be Required. Under Conditional launch, set the device’s root/jailbreak state to Block access. These steps create a secure container for the passkey.
5. Phased Rollout with Targeted CA Policies
Instead of applying new policies to “All” users immediately, use a phased approach with a pilot security group. This allows for testing and validation without widespread impact.
` Create a pilot security group in Azure AD`
`New-MgGroup -DisplayName “Pilot-Passkey-Users” -MailEnabled:$false -SecurityEnabled:$true -MailNickname “notSet”`
` Modify the ‘ALWAYS REQUIRE MFA’ policy to target only the pilot group`
`$policyId = (Get-MgIdentityConditionalAccessPolicy -Filter “displayName eq ‘ALWAYS REQUIRE MFA – Compensating Control'”).Id`
`Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -Conditions @{ users = @{ includeGroups = “id_of_pilot_group” } }`
Step-by-step guide:
First, create a dedicated security group for your pilot users. Then, locate the ID of your MFA CA policy and update its user conditions to target only the members of this new pilot group. This limits the policy change to a controlled set of users for initial testing.
6. Monitoring Registration Attempts with Sign-In Logs
Continuous monitoring is critical. Use Azure AD Sign-In Logs to filter for the passkey registration client application and authentication protocol, allowing you to troubleshoot failures in real-time.
` Query sign-in logs for Microsoft Authenticator registration events (using Graph Explorer)`
`GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=appDisplayName eq ‘Microsoft Authenticator’ and clientAppUsed eq ‘Mobile Apps and Desktop clients’ and authenticationProtocol eq ‘none’`
` Key columns to review: Status, Conditional Access policies applied, Device Info, Risk Detail`
Step-by-step guide:
In the Azure Portal, navigate to Azure AD > Monitoring > Sign-in logs. Add filters for `Application` = Microsoft Authenticator, `Client App` = Mobile Apps and Desktop clients, and `Status` = Failure. Analyze the `Conditional Access` and `Basic Info` tabs for each failure to identify the specific policy blocking successful registration.
- Final Hardening: Device Filter Syntax for Granular Control
Once the rollout is successful, use advanced device filter syntax in your CA policies to gradually tighten controls, explicitly excluding compliant devices from the always-on MFA requirement.` Update the device filter on the MFA policy to exclude compliant OR hybrid joined devices`
`Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -Conditions @{`
` devices = @{`
` deviceFilter = @{`
` mode = “exclude”`
` rule = “device.isCompliant -eq true -or device.trustType -eq \”ServerAD\””`
` }`
` }`
`}`
Step-by-step guide:
This powerful device filter rule modifies your MFA policy to exclude devices that are already marked as compliant or are hybrid joined to an on-premises Active Directory. This refines the policy to only challenge devices that are unmanaged, providing a better user experience for those on compliant corporate hardware.
What Undercode Say:
- Security Cannot Be an Absolute Blocker for Innovation. The passkey rollout dilemma perfectly illustrates that overly rigid security policies can stifle the adoption of more secure technology. The solution isn’t to abandon controls but to architect smarter, layered, and more adaptive ones.
- The Power of Phased, Monitored Deployments. A “enable everywhere” approach is a recipe for disaster. The use of pilot groups, detailed monitoring, and incremental policy tightening, as detailed in the technical commands, is the hallmark of a mature, professional security operation.
The analysis suggests that the initial conflict is a growing pain of evolving identity paradigms. The industry is moving from a device-centric compliance model to a more nuanced, signal-based one that incorporates user risk, device state, and application context simultaneously. Successfully navigating this requires security teams to be as agile and innovative as the technologies they are implementing.
Prediction:
The friction between nascent passwordless technologies and established device governance frameworks will catalyze a significant evolution in Conditional Access engines. We predict the near-future development of “step-up” authentication flows specifically for enrollment actions within Entra ID and other IdPs. This will allow a device to authenticate a user for the purpose of proving its own compliance, seamlessly solving the registration catch-22 and accelerating enterprise adoption of FIDO2 passkeys as the new authentication standard.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: https://lnkd.in/p/du9qMDCN – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
