Attested Device Compliance for Microsoft Entra

Many organizations have pursued a zero trust strategy that involves only allowing managed devices to access sensitive company resources.  

This is done for a few reasons:

• Dramatically reduce phishing attacks by requiring an attacker to have a physical company device to login using stolen credentials (including MFA codes).

• Enhance Data Loss Protection (DLP) controls by only allowing access to resources on machines with those controls in place.

• Revoke access for authorized users if their device falls out of compliance or becomes compromised.

Most organizations use their Identity Provider (IdP) to enforce these controls at the time of login.  But how can the identity provider reliably determine if a device is managed or not?

For organizations using Microsoft Entra as their IdP, Jamf has implemented a Microsoft Partner Compliance API integration which enables Entra to identify Apple devices that are managed and compliant according to Jamf Pro.

However, while this integration is widely deployed and used in small and large production environments globally, the integration is subject to end user experience challenges due to a number of inherent factors including:

• End users having to follow specific steps on their device in order to register their device with Entra properly

• Timing and update delays that may inhibit a user’s ability to access a resource when they should be able to do so

• Intermittent service errors resulting in devices that are marked with the incorrect compliance state, requiring help desk intervention to fix

Thanks to new Apple and Jamf platform technologies, Jamf is now able to eliminate these end user experience challenges while simultaneously improving login security.

Introducing Attested Device Compliance

The Microsoft Partner Compliance API-based integration relies on explicit registration of each Jamf Pro-managed device within Entra and out-of-band signaling before access can be granted. In contrast, Attested Device Compliance leverages secure networking backed by Apple’s Managed Device Attestation technology to signal a device’s management and compliance state in-line with login requests, without requiring any Entra registration or any end user interaction.

This approach completely eliminates many of the challenges faced with the time-sensitive signaling-based Partner Compliance approach used before Attested Device Compliance became available.  However, Partner Compliance may still be used in tandem to Attested Device Compliance for layered protection to extremely sensitive applications or for audit purposes.

From a high-level, instead of leveraging the “Compliant” flag as signaled via the Device Compliance Partner API before a resource is available to a given device using an Entra Conditional Access policy, a “Named Location” is used instead.  This Named Location is defined in Entra by pairs of IP addresses that have been issued to your organization by Jamf’s Security Cloud service.  In effect, any device that is attempting to login via one of these IP addresses will be considered “compliant”, and this is where Attested Device Compliance comes in.

In order to use one of these IP addresses to pass the compliance check, a given device MUST be:

• Enrolled into Jamf Pro

• Attested by Apple as genuine Apple hardware

• Identified cryptographically using attested device identifiers that match a device enrolled into your specific Jamf tenant

• In a Jamf Pro Smart Group that matches satisfactory compliance state

• Free of threats as defined by threat categories in Jamf Security Cloud

Failing any of the above will result in the device to lose its ability to use a trusted IP address, making it appear as an untrusted device according to Entra (blocking access) until the issue is remediated.  Once fixed, the device restores its ability to use the trusted IP again automatically within about a minute.

Partner Compliance Comparison

The below table compares Partner Compliance with Attested Device Compliance, including using the two together.

Solution Overview

This section goes into further technical detail of how Attested Device Compliance works and is deployed in your environment.

Attested Device Compliance works by using:

• A zero-touch deployed, always-on, hardware-bound and native traffic vectoring mechanism (Network Relay) to transmit sensitive data from the endpoint to Entra.

• A highly available policy-based global traffic routing network that provides fast connectivity from any network anywhere in the world.

• Dedicated private global IP address Internet egress (HA source IP pairs) as well as private IPSec Site-to-Site tunnel options for added security/control as required.

The high level end-to-end experience includes:

1. An administrator configures a Network Relay deployment configuration, defines one or more network egresses (Internet IPs or IPSec Tunnels), and the definition of an Entra Microsoft Authentication Access Policy.

2. Apple devices are enrolled in Jamf Pro.

3. The Relay configuration is automatically deployed and activated on the device based upon compliance-based Smart Group membership in Pro.  Device Attestation is performed with Apple’s servers and the device’s tenancy in Jamf Pro is cryptographically verified.  No user interaction or login is required.

4. Entra-bound network traffic generated from browsers or apps on the device is encrypted and cryptographically validated on Jamf’s Global Cloud Edge.  The device’s context is evaluated against access criteria, such as risk level and group membership.

5. If access is permitted, the traffic generated by the device is routed towards Entra via:

   1. A dedicated IP Internet Egress gateway. This uses NAT to present the device’s traffic to appear to originate from one of two highly availability public (global) IP addresses.

   2. A dedicated IPSec tunnel. This uses a Site-to-Site IPSec VPN route to land the device’s packets directly on an enterprise’s own network. NAT is used to present devices with a source IP belonging to a private subnet configured on the LAN/DMZ/VPC.

6. If access is denied (e.g. due to an out of compliance device), the traffic is forward via a “public” IP address, which is not trusted by the organization.

7. Conditional Access polices are matched to permit logins from devices with their traffic coming from trusted IP addresses (using Named Locations), and block traffic originating from non-trusted IPs.

For a technical deep dive into how Jamf’s ZTNA routing architecture works to provide least-privilege, micro-tunnel based access to specific resources only – without exposing internal IPs or subnets to endpoints – see Network Engineer's Guide to Jamf Connect ZTNA.

“My IP on a Map” Sample App Configuration Steps

Thanks to Jamf’s cloud-native and integrated platform, setting up Attested Device Compliance is very straightforward.  We’ll first configure a sample SaaS application to validate Relay-based routing before adding in Entra conditional access policies.

With the appropriate access privileges and rights, this configuration can be completed within an hour.

Pre-Requisties

To configure this solution, you will need the following:

• One or more Apple test devices

  • Note: you can use iOS, iPadOS, macOS, or visionOS devices to test configuration.  They all operate identically with Attested Device Compliance.

• Device(s) are enrolled into Jamf Pro

  • These steps are specific to Jamf, but may be applied to Intune managed devices as well.

• Access to Jamf Pro and Jamf Security Cloud portals

  • A Jamf Pro administrator account with the ability to create an API client credential that can manage Mobile Devices, Mobile Device Smart Groups, Computers, and Computer Smart Groups.

  • A Jamf Security Cloud administrator account with Global Administrator or Access Administrator rights.

    • If you don’t have a Jamf Security Cloud environment, contact your Jamf representative or partner.

• Networked edge infrastructure policy administration.

  • Depending on how you will be connecting to your infrastructure (IdP and/or Firewall integration), an admin with appropriate policy or infrastructure configuration privileges will need to allow traffic from Jamf Security Cloud.

    • Note: You can fully configure device routing without this, but your access and capabilities will be inherently limited until these steps are completed.

Configure Jamf Pro

Step 1: Create or copy a Compliance Smart Group in Jamf Pro

Creating this smart group will help simplify and assignment throughout this guide.  If you have already created a Smart Group that you would like to use for your devices, you may use that instead.

1. Log into Jamf Pro using your Jamf Account SSO or other credentials.

2. Navigate to Devices and select Smart Device Groups.

3. Click the + New button to create a new smart group.

4. Provide an appropriate Display Name, we’d recommend “Compliant Devices”. Provide a description as desired.

5. Select the Criteria tab at the top of the screen, then click + Add.

6. Define one or more criteria that defines a “Compliant” device.

   1. If testing: consider scoping to a single device or group of test devices before extending to a broader population.

7. Click Save to create the Smart Group.

Configure and Deploy a Network Relay Configuration

In this section, we configure the Jamf platform to setup and deploy a Network Relay configuration to managed Apple devices.

Step 1: Configure UEM Connect in Jamf Security Cloud

This steps links Jamf Jamf Security Cloud with Jamf Pro to aid with deployment and on-going validation of device enrollment to ensure only managed devices with appropriate risk levels may use the Network Relay service.

1. Log into Jamf Security Cloud using your Jamf Account SSO or other credentials.

2. Navigate to Integrations and select UEM Connect.

3. Follow the steps in Configuring UEM Connect for Jamf Pro and verify the setup reports a successful connection.

   1. It is strongly recommended to complete the webhook configuration to ensure a seamless user experience immediately following new device enrollments.

Step 2: Configure a Network Relay Activation Profile

1. Navigate to Devices > Activation Profiles.  Select the Create profile button.

2. Select the Network access capability, then click Next.

   1. You may optionally deploy the Security (Network threat protection and mobile threat defense) an/or Content controls (category content filtering) capabilities, however those require added steps of deploying the Jamf Trust app that is not in scope of this document.

3. When prompted for Authentication, select Managed device attestation, then click Next.

   1. If you require always-on connectivity that the user cannot disable, select Locked-down.

4. Provide a Name for the activation profile for easy reference.  We’d suggest "Attested Device Compliance Network Relay”

5. Define a Group to add the devices to that activate using this profile.  We’d suggest “Attested Device Compliance Devices” unless you have an alternative device group policy already.  You can always change this later.  Click Next.

6. Review the configuration then select Save and Create.

Step 3: Deploy the Activation Profile to Devices

This steps requires that UEM Connect was configured successfully.

1. On the screen that appears, make sure the Jamf Pro and iOS/iPadOS/tvOS/visionOS buttons are selected.  Expand Configuration profiles.

2. Under UEM actions, select the UEM group pull down menu and select the Compliance smart group you created in Pro in a previous step.

   1. Note: if your group doesn’t appear when clicked, begin typing the name of the smart group, and it should appear.

   2. If you skip this step, you’ll need to manually scope the mobile configuration profile that is pushed to Pro to a smart group.

3. When ready, click Deploy to Jamf Pro.  This will deploy the Relay configuration to all devices matching the defined Smart Group’s criteria.

   1. Note: At this point, no access policies have been defined so while the Relay configuration will be pushed to the device, no traffic will be routed using it.  We’ll configure that next.

4. Repeat the above steps, but selecting macOS as the platform type if testing with Macs.

Configure a Sample Access Policy

In this section, we configure routing configuration and policies to route select enterprise traffic from the device to an example SaaS destinations to validate routing is working properly before introducing Entra Conditional Access policies.

This guide uses a “Shared Internet Gateway” for simplicity purposes to get Relay-based routing up and running.

For production use, it is strongly recommended to configure and use a Dedicated Internet Gateway or Dedicated IPSec gateway based upon your connectivity and security requirements.  Navigate to Integrations > Access gateways in Jamf Security Cloud to configure private gateways, which then may be easily used instead of a Shared Gateway as configured in this guide.

Step 1: Configure the My IP on a Map Access Policy

1. In Jamf Security Cloud, navigate to Policies > Access policy and click Create policy.

2. Select Predefined App, choose My IP on a Map from the available applications, then click Next.

3. Optionally define a Category, then click Next.

4. The sample hostnames for the My IP on a Map application are already defined.  Click Next to proceed.

5. Optionally select the device groups that should have access to this app, which must include the compliance device group you may have defined earlier (if All is not selected).

6. Enable Access requires device to be managed then click Next.

   1. To simplify testing, we recommend leading risk validation disabled at this point.  Once deployment is validated and risk-based validation is well understood, it is a great feature to enable!

7. On the Application traffic routing screen, be sure that Encrypt and route via ZTNA: is selected, then select Nearest Data Center,

   1. For this specific My IP on a Map test app, we recommend not using a custom access gateway.

8. Leaving other configurations at their default settings, click Next.

9. Review the configuration then click Save and create app.

Step 2: Redeploy the Network Relay Access Policy

1. Navigate to Devices > Activation Profiles and select the activation profile you defined earlier.

2. Expand Configuration profiles then click Deploy to Jamf Pro.

Step 3: Confirm Relay Routing on the Device

1. On a test device, open Safari.

2. Navigate to map.wandera.com

3. If you see an IP address and a map, congratulations!  You’re relay configuration is working correctly.

   1. If you see “Forbidden”, re-check the above steps and make sure the Relay configuration is deployed to your device in the Settings app (or System Preferences for macOS) under VPN & Relays.

Microsoft Conditional Access: Configuring Attested Device Compliance

Using Jamf’s Relay service in combination with Microsoft Conditional Access policies, access can be restricted to trusted Apple devices with a seamless user experience, while enhancing security in the process.

How it Works

1. A managed devices is deployed a mobile configuration profile with Network Relay and ACME payloads.

2. Using Managed Device Attestation, the ACME certificate is issued to the device after the hardware is validated by Apple’s attestation servers.  The private key for the certificate is locked in the device’s Secure Enclave and can never be viewed or shared.

3. A mutual-TLS QUIC/HTTP3 (MASQUE) Relay tunnel is used to encapsulate all Microsoft Entra authentication traffic leaving the device.  This tunnel obfuscates all Entra traffic, protects it from Adversary in the Middle TLS attacks, and leverages QRC where supported.

4. Jamf’s relay service terminates the inbound MASQUE tunnel, verifying the integrity of the device’s identifier via the client TLS certificate while also verifying the device is enrolled into the customer’s linked Jamf Pro tenant and satisfies other compliance and access policies.  The Entra traffic is not decrypted or otherwise modified in this process!

5. Assuming all of those checks are passed, the Entra traffic is egressed to the Internet using tenant-dedicated global HA tenant-dedicated IP addresses.  In other words, only genuine Apple devices, that are actively enrolled and compliant in the customer’s linked Jamf Pro environment is able to use these dedicated Internet IP addresses.

6. These IP addresses are configured as Named Locations in Microsoft Conditional Access configuration.

7. These named locations are used to bypass the typical Jamf Device Compliance policy used for non- Jamf managed (or unauthorized) Apple devices.  The same Named Locations are used for a new Conditional Access policy that permits access from devices originating from the Named Location (IPs) without requiring Device Compliance.

The net effective is effectively the same: instead of sending the device compliance bit to Entra to determine Conditional Access policy, the compliance check is happening on the Jamf platform.  Only managed and compliant devices will ever be able to use the trusted IP / Named Location.  This approach also adds significant user experience improvements (no specific end user setup steps required) while greatly enhancing security by encapsulating and protecting Entra traffic over any trusted or untrusted network the device finds itself on.

Configuring Entra Conditional Access Policies for Attested Device Attestation

Pre-Requisites

• You have successfully configured and deployed the My IP on a Map sample SaaS app.

• You – or a colleague you can work with – has access to configure Microsoft Conditional Access Policies.

Step 1: Create a Dedicated Internet Egress Gateway in Jamf Security Cloud

In this step, you will create a pair of dedicate global (public) IP addresses that will be uniquely available to your organization and no one else.

1. In Jamf Security Cloud, navigate to Integrations > Access gateways.

2. Next to Dedicated internet gateway select Create Gateway.

3. Provide a Name for the gateway and define an Egress region of your choice.

   1. Note: you can create multiple dedicated internet gateways and then “group” them.  This enables the nearest egress gateway to be used for a user that may be connecting to a Jamf point-of-presence in that region.   This configuration is out of the scope of this document, contact Jamf Support if additional assistance is required.

4. Once create, take note of the two Public IPs that are returned.  These will be used in the Named Locations configuration in Microsoft Entra.

Step 2: Create a Microsoft Entra Access Policy using the Dedicated IP Gateway

1. In Jamf Security Cloud, navigate to Policies > Access Policies, then click Create Policy.

2. Select Predefined App, then select Microsoft Authentication from the list of apps that appear.

   1. Note:  It is not required to configure other Microsoft apps as shown in the access policies for Conditional Access controls to work.

3. Optionally define a Category, then click Next.

4. The hostnames for Microsoft Entra are already defined.  Unless you are using a very specialized Entra configuration, click Next to proceed.

5. Optionally select the device groups that should have access to this app, which must include the compliance device group you may have defined earlier (if All is not selected).

6. Enable Access requires device to be managed then click Next.

   1. To simplify testing, we recommend leading risk validation disabled at this point.  Once deployment is validated and risk-based validation is well understood, it is a great feature to enable!

7. On the Application traffic routing screen, be sure that Encrypt and route via ZTNA: is selected, then select the Dedicated Internet Gateway you created in the previous step.

8. Leaving other configurations at their default settings, click Next.

9. Review the configuration then click Save and create app.

Step 3: Re-Deploy Relay Configuration and Validate on the Device

1. In Jamf Security Cloud, navigate to Devices > Activation Profiles and select the activation profile you defined earlier.

2. Expand Configuration profiles then click Deploy to Jamf Pro.

3. On the test device, open the Settings app and navigate to VPNs & Relays.  Select the “i” option next to the Network Relay and verify you see login.microsoftonline.com in the list of hostnames.

Step 4:  Create a Named Location is Microsoft Entra

1. Using an appropriately authorized Microsoft Entra credential, login to Microsoft Entra.

2. In the left-hand navigation under Entra ID, navigate to Conditional Access.

3. Under Manage, select Named locations.

4. Click + IP ranges location.

5. Define a Name, we’d suggest Jamf Relay-Compliant Devices and check the Mark as trusted location checkbox

6. Click the + button to add each IP address that you copied earlier from the Dedicated Internet Egress configuration in Jamf Security Cloud

   1. Be sure to append /32 to the end of each IP address that is entered.

7. When done click Create to create the Named Location.

Step 5: Create an Attested Device Compliance Conditional Access Policy

In this step, we’ll create the policy that will allow Jamf-managed devices - with their traffic egressing via your tenant’s dedicated Jamf IPs – to access the apps and resources they are authorized to use.

1. In Entra > Conditional Access, navigate to Policies.

2. Click + New Policy

3. Provide a Name, we’d suggest Jamf Attested Device Compliance Conditional Access

4. Select Users then select All users

   1. You can define more narrow users here, but since this policy will only apply to devices enrolled into Jamf Pro with the Relay profile deployed, this is usually not required.

5. Select Target resources then specify the resources/apps that users on the managed devices should have access to.

6. Select Network then set Configure to Yes. Select Selected networks and locations, then select the Jamf Dedicated IPs Named Location you created earlier.

7. Under Conditions, optionally define User/Sign-in/Insider risk as appropriate.  Leave other settings Not configured.

8. Under Access controls > Grant, be sure Require device to be marked as compliant is NOT checked.  It is highly recommended to configure either Require multifactor authentication or Require authentication strength settings to leverage Microsoft Authenticator and biometric capabilities.

9. Unless there is a specific reason to do so, leave all settings unchecked in the Session settings of the policy.

10. Verify your settings, then sent Enable policy to On.  Click Create.

Step 6: Exclude the Jamf Named Location from Existing Device Compliance Conditional Access Policies

To avoid access lockouts or other end user impacts, be sure to follow these steps very carefully!

This step is only required if you have used Jamf Partner Device Compliance in your environment to date.

There will be no impact to other devices and no unauthorized devices will gain access by following these steps.

This step modified existing Conditional Access policies to exclude devices that have their traffic originating from your tenant’s dedicated Jamf IPs from being subject to conditional access policies that require the device compliance flag to be set by Jamf Partner Compliance.

1. In Entra > Conditional Access, navigate to Policies.

2. For each Conditional Access policy that requires device compliance but should be usable using Attested Device Compliance, do the following:

   1. Click the Policy name to open it.

   2. Under Assignments, select Network.

   3. If not already configured, set Configure to Yes.

      1. If not specifically configured before, be sure that Any network location under the Include tab is selected.

   4. Select the Exclude tab, and choose the Selected networks and locations option.

   5. Under Select, define the Named Location you created in the previous step.

   6. Click Save when

At this point, there will be no net impact to any device’s ability to access resources via Conditional Access.  Effective policy is exactly the same as before.

Step 7: Verify Conditional Access Policies with What If Tester

In this step, we are going to validate that all necessary conditional access policies have been adjusted for a Jamf managed device to login to a given Entra app using Attested Device Compliance.

1. In Entra > Conditional Access, navigate to Policies.

2. Choose the What if button at the top of the screen

3. Under User, define a sample user that matched in the Attested Device Compliance Conditional Access policy that was just created.

4. Under target resource, select an app/resource that matched in the Attested Device Compliance Conditional Access policy that was just created.

5. Under device platform, select iOS (or other Apple platform per your testing)

6. Under Client app, select Modern apps and desktop clients - modern authentication clients

7. Under IP address, specify one of the Public IPs that were created for the Named Location in a previous step.

8. Under country, select a country that is near the IP address defined.

   1. This is a required step by the What if simulator

9. Click the What if button.

10. In the resulting policies, you should only see the Attested Device Compliance Conditional Access policy created before. If you see other policies:

    1. If the policy indicates it requires device compliance, edit that policy and add the Jamf Named Location as a Network exception per Step 6 above.

    2. If the policy does not require devices compliance, it does not need to be modified, but the Apple device and its user will be subject to whatever additional policies are defined there.

Step 8: Login to a Business App on the Apple Device

With the above configuration in place, you are now ready to login to Microsoft resources on your Apple device using Attested Device Compliance.

1. Open a native app (e.g. Teams) or a browser-based app that requires login with Entra.

2. Login with normal, following MFA prompts as required.

3. If everything works, you’ll be logged in!

   1. If you see “You can’t get tvhere from here” error, there is a problem with your Conditional Access policies for the app you are trying to access.  Please double check configuration using Entra’s “What if” tool.

Step 9: Monitor Usage and Stream Access Events to SIEM (optional)

Now with your Apple devices authenticating with Attested Device Complaince, you can use Jamf Security Cloud to review access logs and stream access events to your SIEM for InfoSec visibility in their SOC.

1. Login to Jamf Security Cloud, navigate to Reports > Event Log.

2. All activity that routes via the service will appear here, including the device name risk posture, and routing disposition.

3. Navigate to Integrations > Data Streams and click New Configuration.

4. Select Network Traffic and specify your SIEM / data destination per our documentation.

FAQ

Q:  Does this approach work with my existing VPN?
A: Yes.  Relays are designed to be compatible with existing VPNs, with Entra traffic routed via Attested Device Compliance.

Q: Does Attested Device Compliance decrypt/inspect my IdP traffic?
A:  No. A secure HTTP/3 tunnel is established between the Apple endpoint and Jamf’s edge servers, through which Entra traffic flows.  The original, unmodified Entra-bound packets from the endpoint are then egressed via an internet gateway with a source IP addresses bound to your organization and not available to any one else.

Q: Will devices be marked as “Compliant” in Entra using Attested Device Compliance?
A: No, however organizations requiring this may still use Jamf’s Partner Compliance integration to signal a device’s compliance state for audit purposes in Entra.  A device’s login-ability (based upon management and compliance state) will be enforced in real-time via Attested Device Compliance, allowing this compliance flag to be set in Entra more “opportunistically” without directly impacting end user experience.