Microsoft Conditional Access via Partner compliance management

Overview

Ensuring end users access organizational data from a trusted device is crucial to many security best practices. Combining Microsoft Conditional Access to validate the user, in conjunction with Addigy to secure the device, allows Apple admins to verify corporate assets are accessed securely.

Please also review Addigy Device Compliance, as it is a key part of the Conditional Access solution and determines how supported devices are calculated as compliant or non-compliant.

Addigy Conditional Access via Partner compliance management supports Mac, iPhone, and iPad. Customers who previously configured this workflow for Mac can now extend Conditional Access decisions to iPhone and iPad.

Also, see Microsoft Conditional Access using Certificates for a Conditional Access workflow that does not require Microsoft Enterprise Mobility + Security E3 or E5.

High Level Technical Overview

Using Addigy Compliance Benchmarks and Microsoft Conditional Access, only devices registered to users and marked as compliant can access data and apps protected by a configured Conditional Access policy.

The Partner compliance management integration follows the same overall flow for supported devices:

1. The device performs Workplace Join so Microsoft Entra ID can identify it.
2. Addigy reads the Entra Device ID and User ID.
3. Addigy submits the Device ID, User ID, and Tenant ID to Microsoft through the Partner compliance management integration.
4. Microsoft evaluates the compliance signal and updates the compliance state on the Entra device record.
5. Microsoft Entra enforces Conditional Access on subsequent sign-ins using that compliance state.

The client-side registration flow differs by platform:

• For Mac, Company Portal is used as the Workplace Join broker.
• For iPhone and iPad, Microsoft Authenticator is used as the Workplace Join broker.

Devices registered through this workflow appear in the Microsoft Entra device list. They are not enrolled into Intune through this integration.

Before you begin

This article includes setup steps that apply to all supported devices, followed by registration and troubleshooting steps that vary by platform. There are two independent decisions to make before you start:

• Platform: Which devices are you registering?
  • Mac (Company Portal broker), or iPhone and iPad (Microsoft Authenticator broker)
  • Covered in: Requirements, Configuring End User Registration, and Troubleshooting each have a Mac section and an iPhone/iPad section.
• Tenant setup: Where are you connecting Addigy to Intune?
  • Single Tenant (Addigy Organization Level), or Multi Tenant (Addigy Policy Level)
  • Covered in: Connecting Addigy to Microsoft Intune - Single Tenant and Connecting Addigy to Microsoft Intune - Multi Tenant, below.

These two decisions are independent of each other: your tenant setup choice doesn't change based on which platform(s) you're registering. Use the Mac-specific sections when configuring Conditional Access for Mac devices. Use the iPhone and iPad sections when configuring Conditional Access for iOS and iPadOS devices. If you're enabling both platforms, you'll work through both sets of sections.

Requirements

All supported devices

• Entra ID P1 or P2 subscription plan with Conditional Access (More information)
  • Entra ID admin rights for the integration connection through the admin consent experience
    • Global Admin, or another admin role permitted by your Microsoft tenant configuration
• Microsoft Enterprise Mobility + Security E3 or E5 for users performing device registration (Find more information here)
• Entra ID user group for Device Compliance registration users
  • Note: This group must contain all prospective Conditional Access registration users and current users. Users should not be removed after registration, as this can cause API post failures on device information updates during check-in or state changes. Adding users to the group does not require a manual re-sync. Sync occurs device-side when Workplace Join registration is started.
• Addigy account using Addigy MDM
• Addigy Security Suite
• Addigy Compliance configured and enabled with at least one benchmark and one rule in that benchmark
  • The compliance calculation against the device record is what sends device compliance data to Microsoft once the device is registered.
• Conditional Access policy is NOT set to All Cloud Apps
  • This will block the User.Read permission used by the Microsoft Partner Compliance API to verify the user during registration. This is due to the SSO Extension using MSAL to call the Microsoft Authentication Broker (Application ID: 29d9ed98-a469-4536-ade2-f981bc1d605e). Today, that application cannot be exempted from the All Cloud Apps scope in the Entra Conditional Access policy UI. If your policy must target All resources, see If your policy must target All resources for a temporary workaround during registration. If a device is stuck unable to register because of this, see Troubleshooting - General.

Mac requirements

• macOS 13.0 or later (see Addigy System Requirements for currently supported macOS versions)
• Microsoft Enterprise SSO Extension (Single Sign-On profile) deployed to Mac devices that will be registered
• Addigy Self Service deployed to the device
• Company Portal for Mac registration
  • Note: The integration installs and manages its own version of Company Portal. You do not need to deploy Company Portal separately.

iPhone and iPad requirements

• iOS 16 or later, or iPadOS 16 or later
• iPhone or iPad enrolled in Addigy MDM
• Addigy Compliance configured and enabled for the device
• Self Service for iPhone and iPad deployed to the device
• Microsoft Authenticator deployed or available to the user
  • Note: Deploy Microsoft Authenticator via VPP (see Configuring Apple Apps: Apps & Books) through a Policy, the realistic way to deploy it at scale, or allow users to install it themselves. In environments using Managed Apple IDs, Authenticator must be deployed by the admin. See the warning below this list about what happens if it's removed.
• Microsoft SSO Extension configured for iPhone and iPad (see Extensible SSO, iPhone and iPad values below)

Technical Workflow - Single and Multi Tenant Steps

Below we discuss the technical workflow connecting Addigy and Microsoft as part of Microsoft's partner compliance management integration, setting up the one-time Conditional Access registration workflow, and configuring Conditional Access policies that grant or deny access based on the device state sent by Addigy.

The overall workflow is shared across supported devices. The main difference is the client-side registration experience: Mac uses Company Portal as the broker, while iPhone and iPad use Microsoft Authenticator as the broker.

Enabling Partner Compliance Management for Addigy

The first step needed to allow for the integration connection between Addigy and Microsoft is to add Addigy as a compliance partner

1. Navigate to the Microsoft Intune admin center 
2. Open the Tenant Administration blade (what is a blade?)
   
3. Open the Connectors and tokens blade
   
4. Open the Cross platform > Partner compliance management blade
   
5. Choose Add compliance partner to start the partner wizard
   
6. Select Addigy from the Compliance partner dropdown in the wizard
   

7. Select the platform you want to configure from the Platform dropdown:

   • Select macOS for Mac devices
   • Select iOS/iPadOS for iPhone and iPad devices

   

   Microsoft manages partner compliance configurations by platform. To use Addigy Conditional Access for Mac, iPhone, and iPad, create the applicable partner compliance configuration for each platform. If you're enabling both Mac and iPhone/iPad, repeat this wizard a second time, selecting the other platform on your second pass.

   Note: Some screenshots in this article may show macOS as the selected platform. For iPhone and iPad, select iOS/iPadOS instead.

8. Click Next to advance.

9. Select the desired user group that will have Workplace Join and Registration ability. If desired this can be a group you define (ex: an organization Department that dynamically updates in Entra ID, a static group of testers you manually add to a user group, or a specific user). This can also be assigned to All Users so that any member of the Entra tenant could perform the registration and have their device become compliant. If All Users is selected, you will need the Object ID for the All Users group when completing the Addigy connection steps. Contact Addigy Support if you need help obtaining this Object ID.

   Note: Please take note of the group selected. You will need the Object ID of that group next.

   

10. Click Next to advance.
11. Review your configuration and confirm and save the configuration via the Create button.
    
    
     The Microsoft Intune admin center session can now be closed as the Addigy partner connection is enabled and waiting for the Addigy side activation and first service heartbeat.
    

Connecting Addigy to Microsoft Intune - Single Tenant (Addigy Organization Level)

With Intune listening for service partner activation, let's start the Addigy to Microsoft connection

1. Navigate to Account > Integrations > 3rd Party Integrations > Microsoft Intune
   
2. Input your Entra Tenant ID in to the Tenant ID box. Then input the Group Object ID of the group you selected in the prior section.
   Note: Clicking Find in Azure will take you to the respective landing pages for the tenant info that holds the Tenant ID and the Groups blade so you can search. Then copy and paste the Group ID.
   Optional: If you want to present users with an internal help article when they are not enrolled in Addigy and attempt to access Microsoft Conditional Access-protected content, enter that URL here.
   
   Note: The Tenant ID can be found on the Entra portal home screen:
   
   
3. With your Entra Tenant ID and Group Object ID entered, click the Connect button
   
   
   
4. In the window that opens for the Entra admin consent experience, perform an Entra sign-in with an account with the proper admin rights to grant domain or global consent to the partner app. After you are signed in, click the Accept button to allow the integration. After consent is accepted, the Addigy Compliance enterprise application is created in Entra. This app has the Application ID of 6bbb2957-99e2-4457-9269-0da766ba04e9.
   
   
   
5. The integration will now process and connect the needed services. Once that process is complete, the UI will show the following green signifiers that the integration connection was successful. Additionally, the Microsoft Intune admin center > Tenant Administration > Connectors and tokens > Cross platform > Partner compliance management will show the Addigy partner listed and with a successful heartbeat as shown in the following example.
   

The connection is now set up. Supported devices can register once the required platform-specific configuration is deployed.

• For Mac, deploy the Microsoft Enterprise SSO Extension configuration and Addigy Self Service. Company Portal is installed automatically by the integration and does not need to be deployed separately.
• For iPhone and iPad, deploy Self Service for iPhone and iPad, Microsoft Authenticator, and the Microsoft SSO Extension configuration.

Connecting Addigy to Microsoft Intune - Multi Tenant (Addigy Policy Level)

With Intune listening for service partner activation from the Microsoft API enabled with Addigy as a partner,  let's start the Addigy to Microsoft connection

1. Navigate to the desired policy for integration then Integrations & Settings > Integrations > Microsoft Conditional Access
   
2. Input your Entra Tenant ID in to the Tenant ID box. Then input the Group Object ID of the group you selected in the prior section.
   Note: Clicking Find in Azure will take you to the respective landing pages for the tenant info that holds the Tenant ID and the Groups blade so you can search. Then copy and paste the Group ID.
   Optional: If you want to present users with an internal help article when they are not enrolled in Addigy and attempt to access Microsoft Conditional Access-protected content, enter that URL here.
   
3. With your Entra Tenant ID and Group Object ID entered, click the Connect button.
4. In the window that opens for the Entra admin consent experience, perform an Entra sign-in with an account with the proper admin rights to grant domain or global consent to the partner app. After you are signed in, click the Accept button to allow the integration.
   
5. The integration will now process and connect the needed services. Once that process is complete, the UI will show a green title bar signifying that the integration connection was successful.
   Additionally, the Microsoft Intune admin center > Tenant Administration > Connectors and tokens > Cross platform > Partner compliance management will show the Addigy partner listed and with a successful heartbeat as shown in the following example.
   

The connection is now set up. Supported devices can register once the required platform-specific configuration is deployed.

• For Mac, deploy the Microsoft Enterprise SSO Extension configuration and Addigy Self Service. Company Portal is installed automatically by the integration and does not need to be deployed separately.
• For iPhone and iPad, deploy Self Service for iPhone and iPad, Microsoft Authenticator, and the Microsoft SSO Extension configuration.

Configuring End User Registration - Mac

The last configuration step is to enable end users to register their device so Microsoft Entra can identify the device and Addigy can send its compliance state to Microsoft.

The following steps apply to Mac registration. For Mac, Addigy Self Service is used to register the device for Microsoft Conditional Access. The Mac registration flow uses Company Portal as the Workplace Join broker and uses Mac-specific components such as the Microsoft Enterprise SSO Extension and MacManage. (iPhone and iPad registration works differently, see the next section.)

Note: Before you enable registration, build the Microsoft Enterprise SSO Extension Device Setting and deploy it to the same devices (see Extensible SSO - Organization and Policy Level below). If users register before the SSO Extension is on the device, registration can fail.

1. Navigate to the Policies page
2. Select the desired policy
3. Click on the Self Service tab
4. Click on the desired Self Service configuration
5. Edit the Self Service configuration via the Edit Configuration button (see Creating and Deploying Self Service for Mac for more on Self Service configurations)
6. Under the Integrations section check the box to enable the Intune integrations inside of Self Service (lower left corner of Self Service app)
   
7. Click Save and Review then confirm that change for deployment
8. Device will now see the registration workflow option in Self Service after policy deployment

Configuring End User Registration - iPhone and iPad

The last configuration step needed to enable end users on iPhone and iPad is to make the registration workflow available in Self Service. This allows the device to register with Microsoft Entra so Addigy can send the device compliance state to Microsoft.

The following steps apply to iPhone and iPad registration. For iPhone and iPad, Self Service starts the registration workflow, Microsoft Authenticator is used as the Workplace Join broker, and the Microsoft SSO Extension configuration must be deployed to the device. (See Configuring End User Registration - Mac above for the Mac equivalent.)

Before end users register an iPhone or iPad, confirm the following are in place:

• The device is enrolled in Addigy MDM.
• The device is assigned to the correct Addigy policy.
• Addigy Compliance is configured and enabled for the device.
• Self Service for iPhone and iPad is deployed to the device.
• Microsoft Authenticator is deployed or available to the user. (see Configuring Apple Apps: Apps & Books for deploying via VPP).
• The Microsoft SSO Extension configuration is deployed to the device (see Extensible SSO, iPhone and iPad values below).
• The user is included in the Entra ID group assigned to the Addigy compliance partner configuration for iOS/iPadOS.
• The Microsoft Conditional Access policy targets the intended users, apps, and device platforms.

Once everything above is in place, including the Microsoft SSO Extension configuration being deployed to the device, enable the registration workflow in the Self Service configuration. This is configured per policy. If the integration is not enabled in the Self Service configuration, end users will not see the registration option.

1. Navigate to your Policies
2. Select the desired policy
3. Click on the Self Service Tab
4. Click on the desired Self Service configuration
5. Edit the Self Service configuration via the Edit Configuration button
6. Under the Integrations section check the box to enable the Intune integration inside of Self Service
   
7. Click Save and Review then confirm that change for deployment
8. The device will now see the registration workflow option in Self Service after policy deployment

After the required configuration is deployed, the user can start the Conditional Access registration workflow from Self Service on iPhone or iPad. Microsoft Authenticator handles authentication and Workplace Join. After registration succeeds, the device appears in the Microsoft Entra device list. The device is not enrolled into Intune through this workflow.

Extensible SSO - Organization and Policy Level

To reduce the number of sign-ins and support the security changes in place after May 2023, please configure the SSOe payload for Microsoft apps and browser sessions. Use the Microsoft prescribed values in the Extensible SSO Device Setting found in Addigy. Read more

The SSO Extension payload is platform-specific. A different Microsoft app hosts the extension on each platform: Company Portal on Mac, and Microsoft Authenticator on iPhone and iPad. Deploy the Mac values to Mac devices and the iPhone and iPad values to iOS and iPadOS devices.

Note: A device can only have one Extensible SSO payload. Deploying more than one SSO Extension payload to the same device will cause a conflict and SSO will fail.

Creating and Deploying the Extensible SSO Device Setting

Build and deploy this Device Setting before you enable registration in Self Service (see Configuring End User Registration - Mac and Configuring End User Registration - iPhone and iPad above). Create a separate Device Setting for each platform you're registering.

1. In Addigy, navigate to Catalog > Device Settings.
2. Click New.
3. Select Extensible SSO, then choose Old (MDM) or Modern (DDM).
4. Enter a Payload Name, then enter the values for your platform from Mac Values or iPhone and iPad Values below, following the allow-list guidance below.
5. Click Create Profile (MDM) or Create Declaration (DDM).
6. Navigate to Policies and select the policy that contains the devices you're registering.
7. Select Device Settings, check the box next to the setting you just created, then click Add/Remove > Add to policy.
8. The Device Setting is sent to devices in the policy on the next policy deployment. Confirm it has deployed before end users start registration.

Note: If you choose Modern (DDM) on Mac, the Extension ID and Team ID go into a single Extension Composed Identifier field: com.microsoft.CompanyPortalMac.ssoextension (UBF8T346G9). For a field-by-field walkthrough of this same screen, see How to Configure Microsoft Platform SSO in Addigy, and skip the Platform SSO fields unless you're also using Platform SSO.

When creating the SSO profile, keep this in mind for the allow-list fields:

• App Allow List: Comma-delimited list of application bundle IDs for the applications that are allowed to participate in SSO. Example: com.contoso.workapp, com.contoso.travelapp
• App Prefix Allow List: Comma-delimited list of application bundle ID prefixes for the applications that are allowed to participate in SSO. This allows all apps that start with a particular prefix to participate in SSO. Example: com.contoso., com.fabrikam.
• The values below are written without a trailing space after each comma. Addigy's Extensible SSO Device Setting UI doesn't reject a space either way, it's just something to keep in mind for consistency when typing these in.

Mac Values

The values to add are:

• Extension ID: com.microsoft.CompanyPortalMac.ssoextension
• Type: Redirect
• Team ID: UBF8T346G9
• URLs
  • https://login.microsoftonline.com
  • https://login.microsoft.com
  • https://sts.windows.net
  • https://login.partner.microsoftonline.cn
  • https://login.chinacloudapi.cn
  • https://login.microsoftonline.us
  • https://login-us.microsoftonline.com
• Extension Data: Microsoft
  • App Allow List
    • com.apple.Safari
    • com.addigy.MacManage
    • com.microsoft.CompanyPortalMac
    • If Chrome is used
      • com.google.Chrome
  • App Prefix Allow List
    • com.apple.
    • com.addigy.
    • com.microsoft.
    • If Chrome is used
      • com.google.
  • Browser SSO Interaction Enabled
    • enabled = On

iPhone and iPad Values

The values to add are:

• Extension ID: com.microsoft.azureauthenticator.ssoextension
• Type: Redirect
• Team ID: Not required for iPhone and iPad. Leave this field blank.
• URLs
  • https://login.microsoftonline.com
  • https://login.microsoft.com
  • https://sts.windows.net
  • https://login.partner.microsoftonline.cn
  • https://login.chinacloudapi.cn
  • https://login.microsoftonline.us
  • https://login-us.microsoftonline.com
• Extension Data: Microsoft
  • App Allow List
    • com.addigy.ios.SelfService
    • If Chrome is used
      • com.google.chrome.ios
  • App Prefix Allow List
    • com.apple.
    • com.addigy.
    • com.microsoft.
    • If Chrome is used
      • com.google.
  • Browser SSO Interaction Enabled
    • enabled = On

Note: On iPhone and iPad, Safari participates in SSO by default, and apps built with the Microsoft Authentication Library (including Microsoft Authenticator and most Microsoft apps) participate in SSO without being added to an allow list. The App Allow List and App Prefix Allow List keys are only needed to extend SSO to additional apps that do not use the Microsoft Authentication Library.

Note: Apple requires that Microsoft Authenticator is installed on the device for the iPhone and iPad SSO Extension to load. Users do not need to open or configure Authenticator; it only needs to be present. See iPhone and iPad requirements above for how to deploy it and what happens if it's removed.

Using Platform SSO on Mac

Platform SSO is a macOS-only feature. It is not supported on iPhone and iPad, so a fleet using Platform SSO on Mac will still use the standard SSO Extension values above for iPhone and iPad.

On Mac, Platform SSO is not a separate payload. It uses the same Extensible SSO Device Setting and the same Mac values above (Extension ID, Team ID, Type, and URLs), with additional Platform SSO settings added to that payload, and requires macOS 13 or later with Company Portal 5.2404.0 or later. See How to Configure Microsoft Platform SSO in Addigy for the full configuration.

If you enable Platform SSO for Mac devices, the Platform SSO payload replaces the standard SSO Extension payload above. Do not deploy both to the same device.

Note: Platform SSO changes how a Mac registers with Microsoft Entra. Registration is performed through the Platform SSO registration prompt using hardware-bound keys, instead of the Self Service registration workflow described below. Platform SSO alone does not send compliance information to Entra. Devices still need to go through the Self Service Conditional Access registration process described in How Conditional Access Registration Works on the Device (Mac) below; PSSO registration and Conditional Access registration are two separate steps.

Recommended order when combining Platform SSO with Conditional Access: register Platform SSO first, then proceed with Conditional Access registration.

1. Complete the Platform SSO registration flow. See Complete the macOS ESSO Registration Flow in the Platform SSO KB.
2. Then proceed with the Conditional Access registration steps described in How Conditional Access Registration Works on the Device (Mac).

If you already have devices registered for Conditional Access and are now adding Platform SSO, contact Addigy Support before proceeding rather than registering PSSO on your own.

How Conditional Access Registration Works on the Device

Mac

1. In Self Service, the user clicks Register device.
2. A Device not registered prompt appears: "Your device must be registered to access email and other services. This could take a minute or two. Please log in when prompted to do so." The user clicks Continue.
3. Company Portal opens and shows its Sign in screen. The user clicks Sign in.
4. The Microsoft Sign in page loads in a "Sign in to Company Portal with single sign-on" window. The user enters their email address and clicks Next.
5. The user is redirected to their organization's identity provider sign-in page and enters their password, then clicks Sign in. Exactly what the user sees here depends on how the organization's identity provider is configured; the video below shows one example.
6. The web view closes. Company Portal shows Checking your Mac..., then You're all set!. The user clicks Done.
7. A separate Sign in to MacManage with single sign-on window opens showing Account found. The user selects the account that was just added and clicks Continue.
8. Company Portal closes. Self Service briefly returns to the Install screen, then shows a confetti animation with Registration complete!
9. In the lower left of Self Service, the Conditional Access State indicator updates from "Not registered" to "Registered" once this completes.

Behind the scenes, steps 4 through 7 above are Workplace Join completing: this creates the device's identity record with Microsoft Entra ID. MacManage then reads the resulting device and user IDs and reports them to Addigy, which submits them to Microsoft through the Partner compliance management integration (see High Level Technical Overview above).

Note: As of Q3 2025, Microsoft has moved Workplace Join private key storage from the Mac's Login Keychain to the Secure Enclave. All new registrations now use Secure Enclave storage by default, with no opt-out, and the Microsoft SSO Extension (or Platform SSO) is effectively required for registration going forward. End users won't see this directly; it doesn't change what they click through. It does mean the SSO Extension deployment in the Mac requirements above isn't optional in practice. If any issues occur during these steps, see Troubleshooting - Mac below.

iPhone and iPad

1. In Self Service, the user navigates to Info, where a Your device is not registered banner appears: "You will not be able to access your company resources until the device is compliant." The user taps Register your device.
2. Self Service opens an in-app web view to the Microsoft sign-in flow (Microsoft Authenticator as the broker). The user enters their email address and taps Next.
3. The user is redirected to their organization's identity provider sign-in page and enters their password, then taps Sign in. (Same as the Mac flow, exactly what the user sees here depends on how the customer's own identity provider is configured.)
4. A Help us keep your device secure prompt appears: "Register your device to continue." The user taps Register.
5. A Registering your device, this may take a minute screen appears while registration completes.
6. Self Service returns to the Info tab, now showing Your device is compliant along with the rules-passed count.

After this completes, the device appears in the Microsoft Entra device list. The device is not enrolled into Intune through this workflow.

Note that applies to both platforms: Once compliance data flows from Addigy through Intune to Entra, the device's registration record will show MDM = Intune in Entra. This is expected behavior for all Partner Compliance Management (PCM) API vendors, not an Addigy-specific quirk, and does not mean the device was enrolled into Intune. See Where do registered devices appear in Microsoft? in the FAQ below for the full explanation.

Creating the Conditional Access Policy in Microsoft Entra

The steps above register your devices and send their compliance state to Microsoft. To enforce access based on that state, create a Conditional Access policy in Microsoft Entra that requires a compliant device. Follow Microsoft's guide: Require device compliance with Conditional Access.

Keep the following in mind when following that guide:

• Target specific apps instead of All resources when you can. Microsoft's guide selects All resources (formerly All cloud apps). A policy scoped to All resources that requires a compliant device also blocks the sign-in Self Service uses to register the device, so the device can never become compliant. Selecting only the apps you want to protect avoids this. If your organization needs the policy to cover All resources, see the next section.
• Compliance comes from Addigy. Microsoft's guide mentions creating an Intune compliance policy first. For devices in this workflow, the compliance state comes from Addigy Compliance, so make sure your Addigy benchmark is configured instead.
• Start in Report-only. Confirm at least one registered device shows as compliant before switching the policy to On.

If your policy must target All resources

Use a temporary user exclusion while each device registers. This only needs to happen once per device: after registration completes, Addigy reports the device's compliance state and the policy is satisfied normally on every sign-in after that.

Note: Apply the exclusion under the policy's Users assignment, not under Target resources. The registration sign-in is evaluated against Microsoft Graph, so excluding the Addigy app from Target resources won't take effect, and excluding Microsoft Graph would open far too much access.

1. In the Microsoft Entra admin center, go to Entra ID > Groups > New group and create a Security group for onboarding, for example CA-Exclusion-Device-Onboarding. Leave it empty for now.
2. Go to Entra ID > Conditional Access > Policies and open your compliant-device policy. Under Assignments > Users, select the Exclude tab, choose Select excluded users and groups, add the group from step 1, and save.
3. Add the user whose device is being registered to the group. Group membership can take a few minutes to apply; if registration still fails right away, wait and try again.
4. Have the user register the device from Self Service (see How Conditional Access Registration Works on the Device).
5. Confirm the device record in Microsoft Entra now shows a compliance status, and the user's latest sign-in log shows your policy as Success or Not Applied rather than Failure.
6. Remove the user from the onboarding group. The device is now compliant, so the policy applies normally.

Repeat steps 3 through 6 for each new device, or keep the onboarding group as part of your device provisioning process.

Note: To test this once before using an exclusion, you can set the policy to Report-only for a single registration attempt. While it's set to Report-only, the policy isn't enforced for anyone in the tenant, so switch it back to On right after.

FAQ

Platform and setup

Does Addigy Conditional Access via Partner compliance management support iPhone and iPad?

Yes. See the Overview above, Mac, iPhone, and iPad are all supported, and customers who already have Mac configured can extend the same workflow to iPhone and iPad.

I already configured Addigy Conditional Access for Mac. Do I need to change anything for iPhone and iPad?

Existing Mac configurations can continue to be used for Mac devices. To support iPhone and iPad, confirm that Addigy is configured as the compliance partner for the iOS/iPadOS platform in Microsoft Intune (see Enabling Partner compliance management for Addigy) and that the applicable users and devices are assigned to the correct Addigy and Entra ID groups.

You also need to deploy the iPhone and iPad registration requirements (see iPhone and iPad requirements) and enable registration in Self Service (see Configuring End User Registration - iPhone and iPad).

Do I need a separate Microsoft partner compliance configuration for iPhone and iPad?

Yes. Microsoft partner compliance configurations are platform-specific, so you'll create one for macOS and, separately, one for iOS/iPadOS. See the platform dropdown step and the callout about repeating the wizard in Enabling Partner compliance management for Addigy.

What's the difference between Single Tenant and Multi Tenant setup, and which do I use?

That's a separate decision from which platform(s) you're registering, see Before You Begin for how the two decisions relate. Single Tenant connects one Entra tenant at the Addigy organization level; Multi Tenant connects a different Entra tenant per Addigy policy (common for MSPs managing multiple customer tenants). The setup steps for each are in Connecting Addigy to Microsoft Intune - Single Tenant and Connecting Addigy to Microsoft Intune - Multi Tenant.

Should I create separate Conditional Access policies for Mac, iPhone, and iPad?

This depends on how your organization wants to target access. Many organizations separate policies by platform so requirements, testing, and troubleshooting can be managed independently, but it isn't required.

Registration and brokers

Is Microsoft Authenticator required for iPhone and iPad registration?

Yes. Microsoft Authenticator is used as the broker for iPhone and iPad registration, see iPhone and iPad requirements for deployment guidance and How Conditional Access Registration Works on the Device (iPhone and iPad) for what that looks like for the end user.

Is Company Portal required for iPhone and iPad registration?

No. Company Portal is the broker for Mac registration only, iPhone and iPad registration uses Microsoft Authenticator instead. See the platform comparison in High Level Technical Overview.

What happens if Microsoft Authenticator gets removed from a device after registration?

Its data is deleted, which can reset the user's authentication state. Deploy it via VPP through a Policy, the realistic way to do this at scale, see iPhone and iPad requirements, and Microsoft Authenticator is not installed or was removed for how to recover.

Is Platform SSO supported for iPhone and iPad?

No. iPhone and iPad use the standard Microsoft SSO Extension configuration for this workflow; Platform SSO is Mac-only. See Using Platform SSO on Mac.

Does enabling Platform SSO on a Mac register it for Conditional Access?

No, not by itself. Platform SSO registration and Conditional Access registration are two separate steps, Platform SSO alone does not send compliance information to Entra. See Using Platform SSO on Mac for the recommended order of operations.

Compliance and what shows up where

Are iPhone and iPad devices enrolled into Intune?

No. Addigy remains the MDM and compliance source for devices managed by Addigy. Microsoft uses the compliance state Addigy sends through the Partner compliance management integration for Conditional Access decisions, the device is simply registered with Entra ID and has a device record. See High Level Technical Overview and Troubleshooting - General if a device isn't showing up where you expect.

Where do registered devices appear in Microsoft?

Devices registered through this workflow appear in the Microsoft Entra device list. They do not appear as Intune-enrolled devices through this integration, even though, once data is sent via API to Intune and Intune relays it to Entra ID to update the Registration record, the record will show MDM = Intune. This is expected for all Partner Compliance Management (PCM) API vendors, not an Addigy-specific quirk, see the note at the end of How Conditional Access Registration Works on the Device.

How often is data sent to Microsoft from Addigy?

Data is sent on an individual device basis after a device audit completes and there is a change in any data (EX: passcode settings, FileVault 2 Status, etc.) that causes a compliance calculation change. By default, device audits occur every 5 minutes, and Microsoft Entra typically updates the device record in 60 to 90 seconds after Addigy sends updated data.

There is also a service heartbeat from the partner service principal. If the API connection heartbeat is lost for 30 days, devices are assumed non-compliant. The heartbeat timestamp can be viewed in the Microsoft Intune admin center under Tenant Administration > Connectors and tokens > Cross platform > Partner compliance management, see also Troubleshooting - API Connection Issues if the connection itself has expired.

Troubleshooting - API Connection Issues

API connections provisioned before the June 2026 release of the revised API Service Principal provisioning workflow may encounter connection errors for backend communication from Addigy to the Microsoft Partner Compliance API.

Example error:
AADSTS700082: The refresh token has expired due to inactivity. The token was issued on <time stamp> and was inactive for <duration in days>. The current token being used for this connection has expired. Try reauthenticating or creating a new connection.

If your connection shows this behavior, disconnect and reconnect your Service Principal Application. This moves the connection from older delegated access to application-based access.

Steps to reconnect with new Service Principal provisioning

Required before you proceed: Ensure that you have access to an Entra ID account with Global Admin, or another permitted admin role, so you can re-establish the API connection. If you do not have access to that account, do not proceed because disconnecting the connector will sever the connection until an appropriate Entra account can reconnect it.

1. Navigate to your Intune 3rd party connection in Addigy:
   Policy Level: Policy > Integrations & Settings > Integrations > Intune
   Organization Level: Account > 3rd Party Integrations > Microsoft Intune

2. Disconnect the connector:
   

   You will receive an alert that this may impact Entra Registered devices. This could impact devices if a connection is not re-established before the next data send is required for new device registrations, or for devices that recently remediated from a non-compliant state. If the API connection is immediately re-established within the next few minutes, this gap should not force devices into a non-compliant state, but they may momentarily be seen as not registered.

3. Wait 60 seconds
4. With the same Tenant ID and Group ID saved in your session from your previous connection, select Connect  to re-establish and re-prompt for the Service Principal API connection:
   
5. Accept the Admin Consent to establish this connection:
   
6. If you get the error:
   "{"message": "There was an error enrolling your organization."}"
   Wait 60 seconds and then retry. The API service may still be awaiting a reply from Microsoft, and a retry after that timeout will work.

Your policy or organization will now be connected with application permissions.

Troubleshooting - General

Devices that have been registered do not show in Intune

This is expected. The Partner compliance management integration is configured in Microsoft Intune, but device records are Microsoft Entra registered only. They are not Intune-enrolled through this workflow. Review the device record in Microsoft Entra.

Error after entering Tenant ID and attempting admin consent

After inputting your Tenant ID and attempting to connect, you get an error on the redirect and admin consent sign-in:

This can happen if Addigy was not added as a compliance partner in Microsoft Intune before attempting the Addigy connection. Confirm that Partner compliance management was enabled for Addigy, then retry the connection.

If Addigy was recently added as a compliance partner, wait briefly and try the connection again. Microsoft may need time to complete the accepted partner registration.

Device or user cannot register because the device is marked non-compliant

This is expected when the Conditional Access policy is scoped to All Cloud Apps (a chicken and egg problem). During registration, Microsoft needs to allow the User.Read call used to verify the user. If the policy applies to All Cloud Apps, that call is blocked before the device can register and become compliant.

Best practice is to target the specific enterprise apps that should require compliant device access instead of using All Cloud Apps. If your organization needs the policy to cover all resources, use a temporary onboarding exclusion instead, see If your policy must target All resources.

Troubleshooting - Mac

Use this section for Mac-specific Conditional Access troubleshooting.

Review Mac registration logs

Looking for more information about the Mac device registration process? Use the macOS Unified System Logs output to see what is taking place for MacManage at registration:

sudo log stream --level=debug --predicate 'subsystem contains "com.addigy"'

Company Portal is being reinstalled or moved on a Mac

For Mac registration, the Conditional Access integration uses Company Portal during registration. Addigy deploys and manages the version used for this workflow. If Company Portal is also deployed separately by policy, this may cause conflicts or repeated movement/reinstallation.

You do not need to deploy Company Portal separately for Mac Conditional Access registration unless otherwise directed by Addigy Support.

Microsoft Enterprise SSO Extension fails to perform Workplace Join

The Apple SSO Extension framework and the Microsoft Enterprise SSO Extension require certain Microsoft domains to be exempted from TLS interception or inspection, also known as break-and-inspect proxying.

Review Microsoft's SSO Extension troubleshooting guidance and ensure the required domains are exempted.

Mac re-registration after a failed or partial registration

Microsoft has moved the Workplace Join private key for Mac registration into the Secure Enclave. Because of this change, the legacy "clear WPJ items from login.keychain" approach is unreliable on current Company Portal builds: there is no longer an exportable keychain item to remove the same way, and Company Portal has also changed the ACLs. (See the Secure Enclave note in How Conditional Access Registration Works on the Device (Mac) above for why this affects detection as well as cleanup.)

Reliable full reset (current Company Portal builds):

1. Delete the device record in Microsoft Entra ID. This must be done manually in the Entra portal, there is no API endpoint provided by Microsoft to request device deletion.
2. Delete the macOS local user account on the device.
3. Create a fresh local user account and re-register from Self Service.

Two independence rules to keep in mind: deleting the Entra record does not clear the local key, and clearing the local side does not remove the Entra record. Both sides must be cleared, skipping one leaves the other stale and the reset incomplete.

Contact Addigy Support if the device still can't register after a full reset.

On older Company Portal builds, the local registration state was stored in the login.keychain and could be cleared by removing these items in Keychain Access.app:

• Kind = Application Password
  • com.microsoft.workplacejoin.cloudEnvironment
  • com.microsoft.workplacejoin.registeredUserPrincipalName
  • com.microsoft.workplacejoin.thumbprint
• Kind = Identity Preference
  • https://device.login.microsoftonline.com (UBF8T346G9.com.microsoft.CompanyPortalMac)
• Kind = Certificate
  • Issued by = MS-Organization-Access
    • CN = Entra Device ID

Note: Older Workplace Join cleanup scripts may not fully reset registration on current Company Portal builds, and can only clean up one MS-Organization-Access certificate at a time. Use them only if directed by Addigy Support.

Troubleshooting - iPhone and iPad

Use this section for iPhone and iPad-specific Conditional Access troubleshooting.

iPhone or iPad cannot complete registration

Confirm that the device has the required configuration deployed:

• The device is enrolled in Addigy MDM.
• The device is assigned to an Addigy policy with Compliance enabled.
• Self Service for iPhone and iPad is deployed to the device.
• Microsoft Authenticator is installed or available.
• The Microsoft SSO Extension configuration is deployed to the device.
• The user is assigned to the Entra ID group selected for the Addigy iOS/iPadOS partner compliance configuration.
• The Conditional Access policy targets iOS/iPadOS and does not unintentionally block the registration flow.

Microsoft Authenticator is not installed or was removed

Microsoft Authenticator is required for iPhone and iPad registration. If it is not installed, the user may be prompted to install it before registration can continue. In environments using Managed Apple IDs, users cannot install apps from the App Store, so Microsoft Authenticator must be deployed by the admin.

If Microsoft Authenticator is removed from a device after registration (for example, if it was deployed through a Policy and later removed from that Policy), its data is deleted. This can reset the user's authentication state and affect the device's compliance status in Microsoft Entra. Redeploy Microsoft Authenticator to the device, then have the user register again from Self Service. See iPhone and iPad requirements for deployment guidance.

iPhone or iPad compliance state is not updating in Microsoft Entra

Confirm that the device has completed an Addigy audit and has an assigned compliance benchmark and rule. Also confirm that the Addigy to Microsoft Intune integration shows a successful connection and heartbeat.

After Addigy sends updated compliance data, allow time for Microsoft Entra to receive and process the updated compliance state.

iPhone or iPad does not appear in Intune

This is expected. Devices registered through this workflow appear in the Microsoft Entra device list. They do not appear as Intune-enrolled devices through this integration.