Cascade Regional Airlines' crew-scheduling application requires that only devices enrolled and marked compliant through device management can sign in, and the identity admin wants a conditional access policy to enforce this. Which Microsoft Entra ID device state must a device be in for a compliance status to exist and be evaluated by that policy?

For a conditional access policy to require a compliant device, the device must first exist as an object in Microsoft Entra ID (through registration, Entra join, or hybrid Entra join) and be enrolled in a device management solution that evaluates it against configured compliance policies (such as encryption or OS version requirements); only then does Entra ID have a compliance attribute to check at sign-in time. That dependency chain — directory presence, then enrollment, then policy evaluation — is the mechanism conditional access relies on, and it's why an unmanaged, unregistered device simply has no compliance state to reference at all. A device with only a local account and no directory relationship is invisible to Entra ID entirely, so there's nothing for the policy to evaluate, and access would be blocked outright rather than conditionally allowed. Novell eDirectory is an unrelated, non-Microsoft directory service with no integration path into Entra ID device compliance and isn't part of this ecosystem. The claim that compliance is unrelated to join type is backwards — join type is precisely the prerequisite that makes a compliance attribute possible to report in the first place. An exam-relevant caveat: hybrid-joined devices need Entra Connect device writeback/sync properly configured for their compliance state to sync correctly. An operational check is confirming a test device shows both a join type and a compliance state of Compliant in the Devices blade before trusting the conditional access policy to allow it through.