Device identities in Microsoft Entra ID: where endpoint and access planning meet
If your team wants to consider devices when deciding who can access an application, start with a simple question: what do we need to know about each device?
Microsoft says Entra ID Conditional Access policies can use factors including the user and the device. Its documentation also connects device registration and joining with device management and Conditional Access. Microsoft Entra ID documentation
That makes device identity relevant to both endpoint and identity teams. It does not, by itself, tell either team which devices should be allowed access.
Keep the person and the device separate
Microsoft distinguishes human identities, which represent people, from device identities, which represent devices such as desktop computers and mobile phones. Microsoft identity and access management concepts
For planning purposes, ask two questions rather than combining them: Who is requesting access? and What do we need to know about the device being used?
There is another distinction worth keeping clear. Microsoft describes authentication as checking who or what an entity claims to be, while authorisation grants or denies access. Microsoft identity and access management concepts We recommend defining the intended access decision before deciding which device information should inform it.
Do not choose a device approach from an overview
Microsoft’s Entra ID overview says devices can be registered or joined for device management and Conditional Access. Microsoft Entra ID documentation The overview does not provide enough detail to choose between those approaches for a particular organisation. It also cannot tell you whether a device in your environment meets your own requirements.
Before choosing a registration, join or policy design, we recommend listing the devices in scope and the information you expect to use. Then validate the relevant product details and your environmental assumptions. Avoid treating the existence of a device identity as an answer to a separate question about the device’s condition or suitability for access.
Consider a hypothetical planning question: your organisation wants to treat devices accounted for through its endpoint process differently from other devices. What would “accounted for” mean in that decision? Which team could explain the status of a device, and what should happen if its status is unclear? These are questions for the organisation to answer, not claims about a particular Entra setting.
Five questions for a joint review
We recommend using this short checklist before discussing configuration:
- What access decision are we considering? Name the application or resource and the proposed difference in treatment.
- Which devices are in scope? Describe the groups plainly instead of assuming every device follows the same process.
- What information would the decision require? Define terms such as “known” or “managed” for this specific proposal.
- Who maintains that information? Name who handles changes in device status and who reviews exceptions.
- What remains unconfirmed? Record product behaviour, available information and local assumptions that must be validated before a rule is applied.
The recommended output is a brief decision record containing those answers and any open questions. If an answer is missing, leave it open rather than assuming the device meets the proposed requirement.
Start with the decision
Device registration, joining and Conditional Access are connected in Microsoft’s Entra ID documentation. Microsoft Entra ID documentation The practical next step is not to pick a setting from that overview. Define the decision first, agree on the device information it would need, and validate the design against detailed guidance and your environment before making a change.
#MicrosoftEntraID #DeviceIdentity #EndpointManagement #Q360