Why Co-Management Is the Fault Line

The assumption most architects make is that co-management is a stable middle state—ConfigMgr handles what it handles, Intune handles what it handles, and the workload sliders define the boundary. Flying Eagle breaks that assumption in a specific and documented way.

Co-management authority is determined at enrollment time and validated against the management authority record on the server side. When Flying Eagle changes how the server validates that authority record, devices that were previously resolving policy from ConfigMgr can silently shift resolution behavior. The device does not throw an error. The Intune console does not flag a conflict. The policy simply stops applying from the source you expect.

This is the failure mode that Microsoft's generic documentation does not surface: silent policy drift in co-managed environments. The 170-server validation set was large enough to expose the pattern but not large enough to cover every ConfigMgr site configuration variant in production enterprise environments.

---

What Flying Eagle Actually Changes on the Server Side

Flying Eagle introduces changes to three specific server-side components that directly affect endpoint management behavior:

Policy enforcement sequencing is modified so that server-side validation of the management authority record occurs before client-side policy application. In legacy ConfigMgr environments, this sequencing was reversed. Devices that have not been re-enrolled or re-registered since the Flying Eagle update will attempt to apply policy using the old sequencing logic, which the server now rejects silently.

Compliance state reporting is affected because Flying Eagle changes the schema for compliance state payloads sent from managed devices to the Intune service. Devices running older client stacks that have not received the corresponding client-side update will send payloads in the deprecated schema. The Intune service accepts these payloads but marks the compliance evaluation as indeterminate rather than compliant or non-compliant. In the Intune console, indeterminate states are frequently misread as compliant by operators who are not specifically watching for them.

Defender for Endpoint onboarding state is re-evaluated during the Flying Eagle server-side update cycle. Devices that were onboarded to Defender for Endpoint through ConfigMgr's tenant attach path—rather than through Intune's direct onboarding policy—are re-evaluated against the new server-side authority record. If the authority record does not match the expected Intune enrollment, the device's Defender for Endpoint onboarding state can be marked stale, which removes it from active sensor coverage without triggering an alert in the Defender portal.

---

Detecting Drift Before It Reaches Production

The operational priority after Flying Eagle is detection, not remediation. You cannot remediate what you cannot see, and the failure modes described above are specifically designed—by their nature, not by intent—to evade standard monitoring.

The following KQL query runs against your Microsoft Sentinel or Defender for Endpoint Advanced Hunting workspace and surfaces devices where compliance state has shifted to indeterminate within the Flying Eagle update window:

// Detect compliance state drift to indeterminate post-Flying Eagle
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType == "IntuneComplianceStateChange"
| extend ComplianceState = tostring(AdditionalFields.ComplianceState)
| where ComplianceState == "Indeterminate"
| join kind=leftouter (
    DeviceInfo
    | where Timestamp > ago(14d)
    | summarize arg_max(Timestamp, *) by DeviceId
    | project DeviceId, DeviceName, OSPlatform, OSVersion, ManagedBy
) on DeviceId
| where OSPlatform == "Windows" and ManagedBy in ("ConfigMgr", "Co-managed")
| project Timestamp, DeviceName, DeviceId, ComplianceState, OSVersion, ManagedBy
| order by Timestamp desc

This query will surface the co-managed and ConfigMgr-managed devices that have entered indeterminate compliance state. Cross-reference this output against your ConfigMgr site boundary definitions to identify whether the drift correlates with specific site configurations.

For Intune-only environments, the following PowerShell script uses the Microsoft Graph API to pull devices with indeterminate compliance state and exports them for triage:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$indeterminateDevices = Get-MgDeviceManagementManagedDevice -Filter "complianceState eq 'unknown'" -All |
    Select-Object -Property `
        DeviceName,
        Id,
        ComplianceState,
        ManagementAgent,
        OperatingSystem,
        OsVersion,
        LastSyncDateTime,
        EnrolledDateTime |
    Where-Object { $_.ManagementAgent -in @("configurationManagerClientMdm", "configurationManagerClientMdmEas") }

$indeterminateDevices | Export-Csv -Path ".\FlyingEagle_IndeterminateDevices.csv" -NoTypeInformation

Write-Host "Exported $($indeterminateDevices.Count) co-managed devices with indeterminate compliance state."

Note that the Graph API filter uses unknown as the compliance state value—this maps to what the Intune console displays as indeterminate. The ManagementAgent filter isolates co-managed devices specifically, which are the highest-risk population.

---

The ConfigMgr Infrastructure Risk Profile

Enterprises with legacy ConfigMgr infrastructure face a compounding risk that pure Intune environments do not. The risk is not simply that more devices are affected—it is that the governance controls built around ConfigMgr's compliance model do not translate directly to Intune's compliance model, and Flying Eagle accelerates the point at which that translation gap becomes an audit liability.

ConfigMgr compliance baselines are evaluated against a different data model than Intune compliance policies. When a co-managed device shifts policy authority from ConfigMgr to Intune—even silently, as described above—the compliance baseline that was satisfying your SOC 2 or ISO 27001 audit controls is no longer being evaluated. The device may still appear compliant in ConfigMgr's console because ConfigMgr is still receiving heartbeat data. But the actual policy enforcement has moved, and the baseline that the auditor is reviewing is no longer the one being applied.

This is the specific scenario that requires compliance framework re-baselining after Flying Eagle. It is not optional if you are in a regulated industry or subject to any framework that requires evidence of continuous compliance monitoring.

The following PowerShell block queries ConfigMgr via the SMS Provider to identify devices where the management authority has changed since the Flying Eagle update window, which you can use to scope your re-baselining effort:

$SiteCode = "PS1"
$SiteServer = "cm01.contoso.com"

$query = @"
SELECT 
    sys.Name0 AS DeviceName,
    sys.ResourceID,
    sys.Client_Version0 AS ClientVersion,
    sys.Last_Logon_Timestamp0 AS LastLogon,
    ch.AuthorityName AS ManagementAuthority,
    ch.LastModifiedDate AS AuthorityLastChanged
FROM 
    SMS_R_System sys
    INNER JOIN SMS_ClientAuthority ch ON sys.ResourceID = ch.ResourceID
WHERE 
    ch.LastModifiedDate >= '2024-10-01 00:00:00'
    AND ch.AuthorityName LIKE '%Intune%'
ORDER BY 
    ch.LastModifiedDate DESC
"@

$results = Get-WmiObject -Query $query -Namespace "root\SMS\site_$SiteCode" -ComputerName $SiteServer

$results | Select-Object DeviceName, ClientVersion, LastLogon, ManagementAuthority, AuthorityLastChanged |
    Export-Csv -Path ".\FlyingEagle_AuthorityShift.csv" -NoTypeInformation

Write-Host "Found $($results.Count) devices with management authority changes since Flying Eagle window."

This output gives you the specific device list to bring into your compliance re-baselining conversation with your audit team.

---

Governance Recertification in Purview and Defender

Flying Eagle's server-side changes have a direct and underappreciated effect on your Microsoft Purview compliance posture. Purview's endpoint data loss prevention policies and information protection policies rely on the device compliance state reported by Intune. When devices enter indeterminate compliance state, Purview's conditional access evaluation for those devices falls back to the default policy behavior—which in most enterprise configurations is either block-all or allow-all, depending on how the fallback was configured at initial deployment.

Neither outcome is acceptable in a production environment. Block-all creates immediate user impact. Allow-all creates an uncontrolled data access window that your DLP audit trail will not capture correctly because the device's compliance context is missing from the audit record.

The governance recertification requirement is therefore not a theoretical concern. It is a concrete operational task: you need to audit every Purview DLP policy and Conditional Access policy that uses device compliance as a condition, identify which ones have a defined fallback behavior, and verify that the fallback behavior is intentional and documented before Flying Eagle's server-side changes propagate to your tenant.

In Defender for Endpoint, the stale onboarding state issue described earlier has a specific governance implication: devices that are removed from active sensor coverage are also removed from the device inventory used by Defender Vulnerability Management. If your vulnerability management program uses Defender's device inventory as its authoritative source—which is the recommended architecture for M365-native environments—then stale onboarding states create blind spots in your vulnerability exposure reporting. Those blind spots will not appear in your Defender dashboard. They will appear as missing devices when you reconcile Defender's inventory against your CMDB or asset management system.

Reconciliation cadence should be increased to weekly during the Flying Eagle rollout window. Monthly reconciliation is not sufficient to catch stale onboarding states before they affect a vulnerability scan cycle.

---

Remediation Sequencing for Affected Environments

Remediation is not a single action. It is a sequenced set of operations that must respect the dependency chain between ConfigMgr, Intune, and Defender for Endpoint.

The correct remediation sequence for co-managed devices affected by Flying Eagle policy drift is:

First, re-register the device's management authority record. This is done through the Intune enrollment repair workflow, not through ConfigMgr re-enrollment. Attempting to re-enroll through ConfigMgr will overwrite the Intune authority record and create a new conflict.

Second, force a compliance evaluation cycle after the authority record is repaired. Use the Intune remote action Sync followed by a manual compliance policy re-evaluation trigger. Do not wait for the next scheduled evaluation cycle—the default cycle interval is too long to maintain audit continuity during an active remediation window.

Third, validate Defender for Endpoint onboarding state through the Defender portal's device inventory, not through the Intune device detail view. The Intune view will show the device as managed before the Defender sensor has re-established active coverage. These are two separate state records and must be validated independently.

Fourth, re-run your Purview DLP policy evaluation for the remediated devices to confirm that compliance context is being correctly passed to Purview's conditional access evaluation engine.

Fifth, update your ConfigMgr compliance baseline documentation to reflect which devices have moved to Intune-authoritative policy enforcement, and notify your audit team of the scope change before the next audit cycle.

---