Listen to this Post
Introduction:
Many organizations configure Conditional Access policies to exclude managed or joined devices from MFA challenges, aiming to reduce friction for trusted endpoints. However, this creates a dangerous attack surface: if an adversary steals a valid username and password, they can register a new device to the tenant without ever being prompted for a second factor, because the device registration flow itself often lacks MFA enforcement. Attackers exploit this gap to establish persistence, bypass location or risk-based policies, and move laterally – all while remaining under the radar.
Learning Objectives:
- Identify how device registration can be abused to bypass MFA when exclusions are misapplied.
- Implement conditional access controls using “impossible” authentication methods and Temporary Access Pass (TAP).
- Audit, monitor, and harden device join/registration processes using PowerShell, Azure CLI, and Entra ID policies.
You Should Know:
- The Device Registration Bypass – How Attackers Exploit the Gap
Attackers who compromise a user’s password can use tools like the Microsoft Entra Join wizard, dsregcmd /join, or Graph API to register a new device against the tenant. If your Conditional Access policy excludes “joined” or “registered” devices from MFA, the registration request itself often inherits that same exclusion – meaning no second factor is ever evaluated.
Step‑by‑step exploitation:
- Attacker obtains a valid user password (phishing, credential stuffing, etc.).
- Attacker runs:
`dsregcmd /join` (Windows) or uses `az rest` to call `/deviceRegistration` via MS Graph. - The device becomes visible in Entra ID under “Devices” without MFA.
- Attacker now uses that registered device to access resources, bypassing any policies that trust “joined/registered” devices.
To see registered devices from your environment (audit command):
Get-MgDevice -All | Where-Object {$_.TrustType -eq "AzureAdRegistered"} | Format-Table DisplayName, DeviceId, AccountEnabled
- Why You Cannot Block Device Registration Entirely – And What Works Instead
Microsoft does not support a “block device registration” grant control in Conditional Access. The claim `”Register device”` cannot be directly blocked via policy. This is a common misunderstanding that leads to false security assumptions.
Instead, you must force MFA during the registration flow. However, standard MFA methods (authenticator app, SMS, phone call) cannot be used because the device being registered has no trusted authentication method yet. The workaround:
Require an authentication method that no unregistered user could possess – such as a certificate issued only to managed devices, or the Temporary Access Pass.
Step‑by‑step workaround:
- Create a Conditional Access policy targeting “All cloud apps” with “Device registration” (under User actions).
- Grant “Require authentication strength” – choose a custom strength that includes “Temporary Access Pass” only.
- Exclude nothing. Apply to all users.
- Now, anyone trying to register a device must present a valid TAP, which your helpdesk issues only after secondary verification.
- Using Temporary Access Pass (TAP) to Secure Device Join/Registration
TAP is a time‑limited, one‑time passcode that acts as a password‑less MFA method. It works even on devices that aren’t yet registered, making it perfect for securing the join flow.
How to configure TAP for device registration:
- In Entra ID admin center, go to Protection > Authentication methods > Temporary Access Pass.
- Enable the policy, set a short lifetime (e.g., 15 minutes) and maximum one‑time usage.
3. Create a Conditional Access policy:
- User actions: Register device.
- Grant: Require authentication strength → create a new strength containing only “Temporary Access Pass”.
- For user onboarding, an administrator generates a TAP:
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "[email protected]" -StartDateTime ([bash]::UtcNow) -LifetimeInMinutes 15
- The user enters the TAP during device registration (Windows Settings → Accounts → Access work or school → Connect → enter TAP).
This blocks attackers completely – they cannot obtain a TAP without already passing an identity check.
4. Auditing Device Registrations for Anomalies
Even with TAP enforced, you must monitor for brute‑force attempts or insider threats. Use Azure Monitor and KQL queries to detect suspicious registrations.
Query to find device registrations without prior MFA (legacy gaps):
AuditLogs | where OperationName == "Add device" | extend DeviceRegistered = tostring(parse_json(TargetResources)[bash].displayName) | extend UserAgent = tostring(parse_json(AdditionalDetails)[bash].value) | project TimeGenerated, UserPrincipalName, DeviceRegistered, UserAgent | order by TimeGenerated desc
For real‑time alerting, create a Sentinel analytics rule that triggers when a device registration occurs from a new IP range or an unmanaged location. Use this PowerShell to list recent registrations:
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add device'" | Select-Object -First 20
5. Hardening Windows and macOS Device Join Policies
Attackers can attempt registration from non‑Windows devices using Graph API. Therefore, client‑side controls are not enough – focus on identity policies.
For Windows:
- Disable user‑level device join via Group Policy:
`Computer Configuration\Administrative Templates\Windows Components\Device Registration\Block user-level device registration` → Set to Enabled. - Apply via Intune: Configuration profile > Administrative Templates > Device Registration.
For macOS:
- Use `profiles` command to enforce that only platform SSO with certificate‑based authentication can register.
For Linux (using `azure-cli`):
- Prevent `az login –allow-no-subscriptions` from performing device registration by configuring Conditional Access to block “Other clients” unless TAP is used.
- Advanced: Combine Device Compliance with MFA Exclusions Safely
If you must exclude joined/compliant devices from MFA, ensure that only devices marked compliant in Intune are trusted. Attackers registering a rogue device will not be compliant automatically.
Step‑by‑step safe exclusion:
- Require device compliance as a grant control in your “MFA exclusion” policy.
- Use a custom device compliance policy that checks for antivirus, OS version, and BitLocker.
- Force all new registrations to go through Intune enrollment (which itself should require TAP or user authentication with MFA).
- Script to check a device’s compliance status from a security perspective:
Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'ATTACKER-DEVICE'" | Select-Object Id, ComplianceState
7. Simulating the Attack – Red Team Validation
To test your own controls, simulate an attacker registering a device without MFA. This validates whether TAP enforcement works.
On a clean Windows VM (no existing Azure AD registration):
dsregcmd /status dsregcmd /join
If registration succeeds without a TAP prompt, your policy is broken.
Using Graph API (simulating cross‑platform attack):
$body = @{
accountEnabled = $true
displayName = "RogueDevice"
operatingSystem = "Windows"
operatingSystemVersion = "10.0.19045"
trustType = "AzureAdRegistered"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/devices" -Body $body
This should fail with `403 Forbidden` if TAP is required. If it succeeds, immediately remediate your Conditional Access policies.
What Undercode Say:
- Device registration is a blind spot – most teams focus on sign‑in MFA but forget that the act of registering a device often bypasses MFA entirely.
- Temporary Access Pass is your silver bullet – it closes the gap without breaking legitimate workflows, as long as you enforce it via authentication strength.
- Monitoring is non‑negotiable – even with TAP, audit logs and KQL queries will catch helpdesk abuse or misconfigurations.
Prediction:
Within 18 months, Microsoft will likely introduce a native “Require MFA for device registration” grant control, but until then, exploitation of this gap will rise sharply – especially as adversaries adopt automated device registration tools. Organizations that fail to implement TAP or certificate‑based join will face MFA bypass incidents that traditional sign‑in logs cannot detect. The future of identity security lies in treating device registration as a high‑privilege operation, equivalent to role assignment or application consent.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nathanmcnulty Do – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
