A secure laptop is not one that happens to have every available protection toggle switched on. Security controls have to be compatible, deployed through the right management channel and evaluated against the risks they are intended to reduce. Microsoft MD-102 tests endpoint administrators’ ability to implement those controls through Intune and connected Microsoft security capabilities. The difficult scenarios are operational: conflicting settings, absent device signals, failed encryption, unmanaged exceptions and identity decisions that do not match endpoint posture.
Suppose a consulting company manages Windows laptops, a smaller macOS fleet and several shared kiosks. Security wants full-disk encryption, anti-malware coverage, firewall configuration and visibility into high-risk devices. Support teams also need recovery when users travel, replace hardware or lose access. Imposing a single undifferentiated baseline would obscure platform differences and may disrupt business applications. A defensible solution maps each protection to the device class, its management authority and the evidence used to prove compliance.
Separate configuration, measurement and response
Endpoint security policies configure settings such as antivirus protection, firewall rules, disk encryption, attack-surface reduction or endpoint detection and response onboarding where supported. Device configuration policies can manage overlapping settings through different administrative workflows. Security baselines provide starting configurations, and compliance policies evaluate whether devices satisfy specified conditions. These concepts overlap in purpose, but they are not equivalent. A compliance rule indicating encryption is required does not necessarily explain which configuration policy successfully enabled the platform’s encryption feature.
Start with a control inventory: why the setting exists, which devices need it, what mechanism enforces it and how success is observed. For encryption, the mechanism may be BitLocker on supported Windows clients and FileVault on supported macOS devices. A compliance rule can help determine whether the endpoint meets the organization’s minimum standard; a recovery-key process ensures that protecting the disk does not strand the user during an authorized recovery. The design is incomplete if an administrator can see ‘encrypted’ but cannot establish whether an appropriate recovery method is available.
Conflict prevention is a design discipline. If a security baseline, settings catalog policy and focused endpoint security policy set contradictory values for the same Windows setting, Intune may report a conflict instead of silently granting the administrator’s preferred value. Do not assume policy priority behaves like the last-edit-wins model of a text file. Choose clear ownership for each group of settings, pilot baseline changes and inspect per-setting reports when the effective result differs from expectations. On mixed device populations, document which settings are applicable and which are unsupported so the lack of a signal is not mistaken for a passing control.
Make endpoint protection layered and testable
Anti-malware controls are important, but the presence of a product icon does not prove a healthy protection state. Verify signatures or intelligence updates, the engine’s operational status, real-time protections and any expected tamper-protection behavior. An endpoint that has been offline for a month can retain a reported policy assignment while falling far behind current threat coverage. Conversely, two competing security products may interfere with one another. Choose a supported product architecture, validate coexistence constraints and investigate the actual telemetry before making emergency changes.
Attack-surface reduction is different from simple signature detection. Rules can constrain suspicious behaviors frequently abused by malware, such as unsafe execution patterns involving office applications or scripts. They can also interrupt legitimate administrative tools. Pilot sensitive rules in appropriate audit or evaluation states where supported, examine event evidence and create narrowly scoped business exceptions only when the risk has been assessed. A blanket exclusion for an entire directory may eliminate both the false positive and the control’s value. The goal is to limit attack paths while maintaining a recoverable support process.
Firewalls have a similarly specific role. Their rules control network communication according to policy rather than serving as a replacement for identity authorization. A laptop with all inbound traffic blocked may still access a malicious site, leak credentials through an allowed outbound application or carry sensitive data into an unauthorized cloud service. Combine firewall decisions with device health, application control, network protections and user permissions. When determining whether a particular rule helps, specify the traffic direction, endpoint, protocol, profile and business requirement. ‘Enable the firewall’ is not a complete design statement.
Treat encryption as an operational service
BitLocker planning involves more than selecting an encryption algorithm. Devices vary in hardware readiness, ownership, provisioning history and recovery-key escrow state. A corporate device might be configured for automated encryption during enrollment, whereas a legacy laptop may need a staged remediation plan. Evaluate disk status and recovery readiness before enforcing a disruptive protection requirement. Know how the team will respond to TPM changes, motherboard replacement, firmware operations and unusual recovery prompts, and determine who is authorized to retrieve keys.
Key recovery is a privileged security operation. Keep it auditable and use least privilege; technicians should not circulate recovery keys in broad chat channels. A recovery key that is available to everyone undermines the confidentiality goal of encryption. Emergency access needs its own controls and event logging. Administrators should also be able to distinguish disk encryption from encryption in transit, and from application-level protection of documents or data. The broader distinction between symmetric and asymmetric encryption is useful when discussing how keys protect data, but examination scenarios tend to ask for a functioning deployment and recovery model.
Platform differences matter. A policy appropriate for modern Windows laptops may not map directly to macOS, shared kiosks or personal mobile devices. Avoid interpreting ‘all devices’ as a uniform operating-system image. A device that cannot support a required control may need a limited access path or an approved replacement, not an undocumented exception that silently removes security. Record those cases with owners, scope and review dates.
Connect protection signals to identity decisions
Intune can integrate with Microsoft Defender for Endpoint to provide device-risk signals and support security operations workflows. Device compliance and Microsoft Entra Conditional Access may then help decide whether a device is suitable for access to a resource. These are linked controls with distinct responsibilities: Defender provides threat information, Intune manages and evaluates endpoints, and the identity layer evaluates access policy. An attacker may compromise an account on a healthy laptop; a compromised laptop might have a user with legitimate credentials. Both dimensions matter.
Consider a device marked high risk after a malicious process is detected. The security team needs to inspect the alert, determine whether isolation or remediation is justified and assess whether the device should continue accessing protected resources. The endpoint team needs to establish policy status and communicate with the affected user. A Conditional Access requirement tied to compliance can prevent access under the configured rules, but it does not itself clean the device. Removing an access restriction without validating remediation can reintroduce the risk.
Examine dependencies before enforcement. An unmanaged Windows device will not magically become compliant because a policy says ‘require compliant device.’ Test enrollment, reporting frequency, supported clients and emergency access. Use a staged rollout and inspect sign-in and device reports. Microsoft SC-300 covers the identity administration dimension; MD-102 focuses on configuring and maintaining the endpoints that supply part of the trust evidence. Boundaries between responsibilities can improve response time if teams agree on escalation and ownership before an incident.
Debug conflicting settings and misleading dashboards
When an endpoint security setting fails, first determine which control family owns it and what evidence is being examined. A device can be enrolled but not receive a targeted security profile; it can receive a profile but report a setting conflict; it can report policy success while a required agent fails to onboard; or it can be configured correctly but remain marked noncompliant due to a different requirement. These are not interchangeable errors. Query assignment scope, platform applicability, effective setting status, check-in times and device diagnostics in that order.
A common failure is applying a security baseline and then setting a conflicting value through another profile to accommodate one application. The result may be conflict reports across hundreds of devices. Narrowly redesign the conflicting control instead of repeatedly syncing the affected machines. Another failure is forcing antivirus exclusions across the fleet when only one signed, reviewed component needs a specific exception. Document exactly what process or path is implicated, why the exclusion is needed and when it will be reassessed. Security hygiene includes removing obsolete exceptions.
Reporting should distinguish deployment success from actual risk reduction. Useful measures include encryption coverage with recoverable keys, protection-agent health, count and age of setting conflicts, risk alerts pending action, devices missing policy contact and time to remediate exposed endpoints. A chart claiming ‘100% policy assigned’ can be dangerously reassuring if half the devices have not checked in recently. Make the denominator explicit and the data timestamp visible.
Design a sustainable control ownership model
Large tenants require delegated administration. App teams may need to troubleshoot installations; endpoint engineers configure settings; identity administrators manage access policies; security responders handle investigations. Broad permissions for everyone create a new attack path. Apply role-based access control and scope management appropriately, with review for high-impact policy alterations, device wipe actions and key recovery. Monitor unexpected assignment changes because an attacker with management access can weaken many devices at once.
Security updates should move through representative test devices before general enforcement whenever the threat urgency allows. Include hybrid workers, specialized hardware, virtual endpoints and remote support workflows. Track known incompatibilities and maintain a documented rollback route; a control that repeatedly disables a critical workflow may lead users to seek unofficial workarounds. Clear, narrowly written exception handling is part of a strong security design, not a concession to weak security.
The core MD-102 skill is reasoning from specific risk to specific control and then to verified device state. Ask what has been configured, what has been measured, who can change it and what should happen if it fails. Security policies become effective only when each of those questions has a reliable answer, and when a help-desk engineer can trace a device’s posture without removing safeguards simply to clear a ticket.