Microsoft 365 Device Registration & Conditional Access for Apple Devices

When working with a customer recently to implement JAMF Device Compliance with Entra, I noticed something unusual in their Conditional Access policy.

“This question led me to dive deeper into the purpose of device registration“

In addition to requiring device compliance and MFA, their policy also included the condition that devices be registered in Entra. This made me really think about the assumptions that come into play regarding device registration, and the mystery surrounding Apple devices.

This question led me to dive deeper into the purpose of device registration, how it fits into workflows like JAMF compliance reporting, and—most importantly—whether relying on registration alone creates vulnerabilities, especially in the context of token theft.

Device Registration and JAMF Compliance

JAMF’s documentation recommends setting Conditional Access policies based on device compliance, which ensures that only compliant devices (those meeting criteria like up-to-date OS versions and encryption) gain access to resources. This workflow already requires registration as part of the setup, but JAMF doesn’t explicitly mention requiring registration in Conditional Access rules. Why? Because registration is already baked into the process of reporting compliance.

When we’re not using compliance, we could consider using registration to grant access, but this introduces a major possible vulnerability: token theft.

Leveraging Token Theft with Registration

For non-technical readers, token theft involves intercepting a piece of code during your login that can be used to unlock access to your account from anywhere in the world.

“Once a malicious actor has a stolen token, it can then be used to register any device into Entra without a safeguard.“

In the context of Conditional Access, this vulnerability is exploited and becomes a major security concern when allowing basic registration. Once a malicious actor has a stolen token, it can then be used to register any device into Entra without a safeguard.

Don’t believe me?  Look here: https://labs.jumpsec.com/tokensmith-bypassing-intune-compliant-device-conditional-access/

What Is Device Registration?

Device registration is the process of adding a device into Entra and linking it to the account used to register. This record can then be used for tracking purposes.

Unlike compliance, which verifies that a device meets security standards, registration simply records basic information about the device. For example, a registered device will include details like the device name and OS version but won’t verify encryption or OS updates. Registration creates a baseline record in Entra but doesn’t enforce any security policies on the device itself.

Domain Join vs Register.  (AADJ vs. AADR)

Azure AD Domain Join (AADJ) is specific to Windows devices, enabling device management baselines and improving user experience through features like Single Sign-On (SSO), while Azure AD Device Registration (AADR) applies to non-Windows devices like Macs and iPhones. AADR is also where BYOD Windows devices go. (BTW Macs used to join domains but anymore so lets clear that up)

Device Registration in JAMF Workflows

Registration is part of the workflow to get Macs reporting compliance information in JAMF. It’s the first step before JAMF can report the compliance status of the Mac. The compliance status is reported in Entra via JAMF and shown on the device record.

Best Practices for Securing Registration

The only way to ensure attackers can’t exploit stolen tokens and use them to register unauthorized devices is to ensure we secure the registration process.

Here are some best practices to lock down the registration process and prevent the token theft problem:

• Use network and location-based conditions in your policy to exclude registration outside your organization’s IPs.
• Require MFA via Temporary Access Passcodes (TAP) for registration. These codes should be provided or used by IT only and can be one-time use only. This affords the highest level of protection.

What If Our Environment is “Complicated”

Organizations often allow access to certain resources for registered (but not compliant) devices, especially in environments rolling out compliance policies gradually. While this is a pragmatic approach and often required by leadership, it means we must ensure security on the registration process is air-tight.

By securing the registration process, organizations can rely on the registration condition alone while they transition to more robust compliance policies.

So, do we need to add it to our policy?

Reflecting on that initial Conditional Access policy, it’s clear that while adding registration as a condition might seem helpful, we don’t need it for the compliant Mac policy. For our other device policies relying on registration alone, it can work ONLY if the registration process is secured. By locking down registration workflows, we can have confidence we’re not susceptible to these emerging threats.  

Scott Morabito is a technologist and founder of TechTonic.  He is a computer scientist and resides in Concord MA