MD-102 includes a large list of Intune and Microsoft 365 features, but the durable concepts are simpler: identity, management authority, ownership, desired state, compliance, least privilege, deployment lifecycle, protection, app/data boundaries, targeting, observability and automation. These ideas connect every objective and make unfamiliar feature questions easier to reason about.
The current MD-102 July 24 blueprint uses those concepts across five weighted domains.
Concept one: device identity is not the same as enrollment
A device can be registered or joined in Entra ID and still not be managed correctly by Intune. Identity establishes who/what the device is; enrollment establishes the management channel.
Troubleshooting should ask which layer failed before treating “device exists” as proof of management.
Concept two: ownership influences the control model
Corporate Windows, corporate Android, personal iPhone and BYOD scenarios should not all receive identical controls. Ownership affects enrollment method, privacy expectations, wipe/retire behavior and app-data protection.
The best policy respects business need and device ownership.
Concept three: targeting determines effective desired state
Groups, dynamic membership, filters, scope tags and enrollment-time grouping decide which user/device receives a profile or app. A correct setting assigned to the wrong scope is still an operational failure.
Targeting should be reviewed before rewriting configuration.
Concept four: compliance is an assessment, Conditional Access is enforcement
Intune evaluates whether a device meets compliance requirements; Entra Conditional Access decides whether the user/device context is allowed to access a resource.
Conditional Access connects security state to business access without merging the two systems.
Concept five: deployment is a dependency chain
Autopilot depends on device identity, enrollment, networking, assigned apps/profiles, Enrollment Status Page and user/device context. A failure at one dependency can stall the whole experience.
Autopilot troubleshooting is therefore about locating the first failed stage.
Concept six: least privilege should be temporary and scoped
Windows LAPS, Endpoint Privilege Management, role assignments and local-group management all support reducing standing privilege.
Administrative capability should be granted to the minimum identity, task, device and duration needed.
Concept seven: protection is layered
Antivirus, firewall, ASR, BitLocker, App Control, security baselines and Defender EDR protect different attack paths. No single policy makes an endpoint “secure.”
Defender for Endpoint adds detection/investigation while Intune manages much of the preventive configuration.
Concept eight: application control can be device-centric or app-centric
Full device management can deploy and configure apps broadly, while MAM/app-protection policies can protect corporate data inside apps on unmanaged/BYOD devices.
This distinction is central to modern endpoint privacy and security.
Concept nine: updates are controlled change
Update rings, feature/quality updates, Autopatch, Hotpatch and platform-specific updates change fleet state at scale. Pilot groups, monitoring and rollout design reduce business risk.
“Install latest everywhere immediately” is not always the most operationally mature answer.
Concept ten: observability turns management into operations
Reports, Endpoint Analytics, proactive remediation, Graph/PowerShell automation, KQL device queries, Copilot agents, service health and alerts show whether policies are effective and users are productive.
Concept eleven: scope is part of security. Intune roles, scope tags, groups, filters and multi-admin approval decide not just what settings exist but who can change them and which devices receive them. Administrative design is a control surface in its own right.
Concept twelve: enrollment type expresses trust and ownership. Corporate automated enrollment, personal enrollment and Android work-profile/dedicated modes give different levels of control. Choosing the wrong enrollment model can create privacy, support or security problems later.
Concept thirteen: cloud management still depends on network access. Autopilot, app install, policy sync, Defender onboarding, certificate issuance and reporting all need endpoints to reach Microsoft or organizational services. A device that cannot communicate will look like a management failure even when policy is correct.
Concept fourteen: device state is eventually consistent. Group membership, policy assignment, sync, evaluation and reporting can take time. Administrators should distinguish normal propagation delay from genuine failure before making duplicate changes.
Concept fifteen: policy conflict is a design problem. When multiple profiles set incompatible values, the platform can report conflict but cannot decide business intent. The administrator should establish one authoritative configuration path.
Concept sixteen: support actions should preserve ownership boundaries. Sync and diagnostics are low impact; retire, wipe and reset are much more consequential. The right action follows device ownership, user lifecycle and recovery requirement.
Concept seventeen: certificates are another identity system. Cloud PKI, SCEP/PKCS-style certificate use and tunnel/Wi-Fi/VPN scenarios rely on trust chains and renewal. Certificate expiration can look like a network or authentication failure.
Concept eighteen: monitoring needs a baseline. Endpoint Analytics scores, app reliability and service health become meaningful when the team knows what normal looks like. Without a baseline, every variation can appear urgent.
Concept nineteen: remediation should be idempotent and measurable. A proactive remediation script can run repeatedly across a fleet, so it should detect state, correct only what is necessary and report the result. Scripts that create new drift are worse than manual support.
Concept twenty: current endpoint administration is cross-platform. Windows remains central, but Apple, Android, specialty devices and cloud PCs all appear in the live blueprint. A policy decision should begin with platform capabilities rather than assume Windows behavior everywhere.
Concept twenty-one: app and device security can be decoupled. MAM lets organizations protect business data in apps when full enrollment is unnecessary or inappropriate. This concept explains many BYOD questions better than memorizing individual settings.
Concept twenty-two: operational improvement is a domain, not an afterthought. Reporting, Graph automation, Endpoint Analytics, Copilot agents, proactive remediation, health alerts and service communications all exist because large endpoint estates need continuous management after initial deployment.
Concept twenty-three: cloud services are dependencies. Intune, Entra, Defender, app stores, certificate services and Windows 365 all rely on service availability and network reachability. Endpoint state must be interpreted in that wider environment.
Concept twenty-four: configuration and reporting are different views. A profile object describes desired state; device status/reporting describes what actually happened. Administrators need both to prove management success.
Concept twenty-five: group membership is part of change control. Dynamic membership can move devices into or out of policy scope automatically, so rule changes can have broad downstream effects even when no profile is edited.
Concept twenty-six: remote actions are lifecycle decisions. Wipe, retire, restart, sync and key rotation have different risk and recovery characteristics. The administrator should choose the minimum action that solves the business need.
Concept twenty-seven: fleet scale changes troubleshooting. A problem affecting one endpoint suggests local state; a problem affecting one model or group suggests assignment/configuration; a tenant-wide issue suggests shared policy or service health. Blast radius is diagnostic evidence.
Concept twenty-eight: endpoint experience is measurable. Startup, app reliability, restart frequency and health scores can be treated as operational SLO-like signals rather than subjective user complaints alone.
Concept twenty-nine: automation identity matters. Graph and PowerShell actions run under users, apps or managed identities with specific permissions. A script that works for a global admin may fail correctly under a scoped service identity.
Concept thirty: change should be validated after deployment. Whether the change is security policy, app, update, Autopilot profile or remediation, the administrator should confirm actual device state and user outcome before considering the work complete.
Concept thirty-one: desired state is convergent, not instant. Intune repeatedly evaluates and applies management intent over time. Administrators should account for sync and evaluation cycles instead of assuming one portal save produces immediate universal state.
Concept thirty-two: security and user experience must be balanced deliberately. An ASR rule, app restriction or update deadline can reduce risk while interrupting legitimate work. Pilot groups and monitoring let the organization tune that balance with evidence.
Concept thirty-three: recovery credentials are sensitive management data. BitLocker recovery keys, local-admin passwords and certificate secrets should be exposed only to authorized roles and audited appropriately.
Concept thirty-four: app deployment and app protection answer different questions. Deployment asks whether the app is present and updated; protection asks what corporate data can do inside the app. Both can be required for the same user.
Concept thirty-five: operational ownership continues after successful enrollment. Monitoring, updates, app health, security alerts, analytics, service communications and remediation are what keep a large endpoint estate reliable after day one.
Concept thirty-six: platform capability sets policy limits. Windows, macOS, iOS/iPadOS, Android, Teams Rooms, HoloLens and Zebra do not expose identical controls. Endpoint management should express a business requirement in the best native control for each platform.
Concept thirty-seven: support evidence should precede destructive recovery. Diagnostics, policy status, app logs, KQL device queries and service health can often explain a problem before retire, wipe or reenrollment is considered.
Concept thirty-eight: fleet management is a feedback system. Desired state is deployed, reporting measures effective state, analytics finds recurring problems, remediation corrects them, and policy is improved. That loop is the core operational idea behind the current MD-102 update.
Concept thirty-nine: offboarding is part of management quality. Retiring or wiping devices, removing stale identities, rotating keys, revoking access, and cleaning assignments prevents old endpoint state from remaining trusted indefinitely. A mature endpoint program manages the full lifecycle from first enrollment to final removal.
Concept forty: service health is part of endpoint evidence. When many unrelated devices fail in the same way, administrators should consider tenant or Microsoft-side dependencies before editing healthy local policy. Blast radius helps identify the responsible layer.
Within the broader Microsoft certification path, MD-102 now validates endpoint operations, not just endpoint configuration. The role is complete only when the administrator can detect drift, diagnose failures and improve the fleet after deployment.