Microsoft MD-102: Identity, Compliance and Access

Microsoft MD-102 treats device identity, compliance, authentication, and access as connected but distinct states. That distinction matters because a user can have a valid identity, a correctly enrolled device, a failed compliance signal, and an application access decision that depends on still another policy. Candidates who collapse those states into one “device is managed” concept tend to troubleshoot the wrong layer.

MD-102 remains current on October 6, 2026, with an English skills update scheduled for October 27. The current pre-update blueprint still rewards the same durable reasoning: know what each state means, where it is evaluated, and which evidence shows why a user or device received the final result.

Separate device identity from device compliance

Registration, Microsoft Entra join, hybrid join, Intune enrollment, ownership, and compliance answer different questions. Identity tells you which device object and user relationship exist. Enrollment tells you whether the device is under management. Compliance tells you whether defined health or configuration conditions are currently satisfied.

Trace one device through all of those states and deliberately create disagreement. A device can be enrolled but noncompliant, or registered without being fully managed. Understanding those combinations is more useful than memorizing a list of status values because it tells you which system should be checked when a later access problem appears.

The distinction becomes especially important with personally owned devices. An identity can be known and an application can be authorized even when the device is not enrolled for full management. App-protection or authentication controls may still satisfy the business requirement. Treating every device as either fully managed or completely untrusted hides the more nuanced control options that endpoint administrators have to evaluate.

Design compliance policy around measurable risk

Compliance policy should express a security or operating requirement that can actually be evaluated. Encryption, operating-system version, threat state, password requirements, and similar signals are useful when the organization can explain why a failed state matters and how the user is expected to recover.

Do not stop at the rule. Define grace periods where appropriate, user notification, remediation ownership, and what happens if the device never returns to compliance. Reporting should show both current state and drift over time. That turns compliance from a checkbox into an operating control tied to measurable risk.

Understand the handoff to Conditional Access

MD-102 compliance and Conditional Access meet at the access decision, but they are not the same control. Intune determines device compliance; Microsoft Entra can require a compliant device along with identity, application, risk, authentication, or session conditions.

Work through a sign-in where the device is noncompliant, then another where the device is healthy but the user fails a different sign-in requirement. Read the policy evaluation and device state side by side. That exercise makes it clear why changing Intune settings cannot solve every blocked sign-in and why an access denial does not automatically prove a compliance problem.

Treat authentication strength as a separate design choice

Authentication methods and authentication strength answer how confidently the organization wants to establish identity for a particular action. They should not be confused with device compliance. A managed laptop may still require phishing-resistant authentication for a sensitive administrative task, while a lower-risk resource may accept a different method.

Compare ordinary workforce access, privileged administration, remote contractor access, and emergency recovery. For each case, decide what authentication assurance is required, how recovery works if the preferred method is unavailable, and what evidence should show the user satisfied the requirement. The goal is appropriate assurance, not maximum friction.

Authentication recovery deserves the same attention as normal sign-in. A strong authentication method is valuable only if onboarding, device replacement, and lost-method recovery are secure and supportable. Temporary Access Pass, help-desk processes, and emergency paths can become weaker routes into the account if they are not designed with the same assurance goals as steady-state authentication.

Use groups and assignments deliberately

Policy correctness depends on targeting. A well-designed compliance rule, configuration profile, or application can still fail operationally if the intended user or device never enters the assignment scope, is excluded, or receives a conflicting assignment. Dynamic membership timing and filters add more variables that must be separated from the policy content itself.

Build a small pilot, production, exception, and emergency targeting model. For a representative user and device, list every relevant assignment and predict the effective result before looking at the portal. This makes scope visible and discourages permanent exclusions that exist only because nobody understands which policy actually wins.

Group design should also consider how membership changes. Static emergency groups, dynamic production groups, user-targeted assignments, and device-targeted assignments create different timing and ownership characteristics. A policy that depends on a dynamic rule may not take effect at the same moment as a direct assignment. Understanding that delay helps separate a policy defect from a membership or propagation issue.

Assignment design should also be tested for change. If a device moves from pilot to production, a user changes role, or a filter condition changes, the effective policy set can shift without any individual policy being edited. Review effective assignments after those transitions. This helps distinguish configuration drift from expected scope changes and keeps troubleshooting focused on why the target received a particular set of controls.

Plan for enrollment and lifecycle transitions

Device state changes throughout its life. A corporate Windows device may be provisioned, repaired, reset, reassigned, replaced, lost, or retired. Personally owned mobile devices may enter and leave management without the organization owning the hardware. MD-102 enrollment and device lifecycle is therefore closely connected to identity and compliance.

For each transition, decide which device object remains valid, what management state should change, whether corporate data must be removed, and what stale compliance or ownership information needs cleanup. Lifecycle work is where seemingly small inventory problems can turn into security or access problems if old state remains active.

Lifecycle transitions should include data consequences. When a personal device leaves management, corporate application data may need selective removal without affecting personal content. When a corporate device is retired or wiped, the organization may need stronger assurance that credentials, keys, and cached business data are no longer usable. These are endpoint decisions with direct security and user-experience consequences.

Troubleshoot the full access chain

When a user reports that an application is unavailable, begin with evidence rather than policy editing. Confirm the user and resource, inspect the sign-in result, identify the device object involved, check management and compliance state, then review the policy conditions that actually applied. If those layers are healthy, continue into application assignment or authorization rather than weakening access controls.

Mixed-state cases are valuable practice. A compliant device can still fail an authentication requirement; an unmanaged device can still reach a resource if the policy does not require management; and a correctly scoped policy can be irrelevant if the application enforces its own downstream permissions. The skill is finding the first incorrect state.

Use logs to preserve ordering. A device may become compliant after the sign-in that was denied, or a policy change may not yet have propagated when the user retries. Timestamps across Intune state, sign-in evaluation, and application events can explain outcomes that look contradictory when viewed only as current snapshots. Exam scenarios may compress those timelines, but the same reasoning helps identify which state existed when the access decision was actually made.

Protect exceptions and emergency access

Exceptions need an owner, reason, scope, monitoring, and review date. Emergency access requires even stronger discipline because it is intentionally designed to survive failures in normal controls. Test those paths without allowing temporary exclusions or break-glass assumptions to become the ordinary access model.

Measure readiness by policy reasoning

Strong readiness is visible when you can explain why the user received a particular outcome and how that outcome changes when one variable changes. Replace a compliant device with an unmanaged one, increase resource sensitivity, change the authentication requirement, or remove an assignment. The reasoning should update without forcing you to relearn the entire scenario.

The responsibilities behind Microsoft 365 Certified: Endpoint Administrator Associate require that kind of cross-domain judgment. Endpoint administrators need to know what they own, which evidence they can trust, and when an access problem belongs to identity or application teams instead.

A good final exercise is to hold the resource constant and change only the actor or device. Compare a normal employee on a compliant managed device, the same employee on an unmanaged personal device, a privileged administrator, and an external user. If you can explain why the authentication, compliance, and access requirements change without losing track of which service owns each decision, the policy model is coherent.

Do one final comparison between prevention and recovery. A strict policy can reduce exposure, but the environment also needs a way to restore legitimate access when a user replaces a device, loses an authentication method, or moves between management states. If your design explains both how access is restricted and how a valid user returns safely, the identity/compliance model is much closer to production reality.

Use the final scenarios to confirm that every exception, recovery path, and access decision still has an accountable owner.