Design security solutions for infrastructure
Server, Client, IoT, and OT Endpoints
CoreSpecify differentiated endpoint baselines and operational controls for servers, clients, mobile devices, embedded systems, IoT, and safety-sensitive OT environments.
Aligned to SC-100 skills measured as of October 21, 2026; candidates testing earlier should review the transition note in the lane overview.
Why this matters
Endpoint architecture cannot assume one management agent, patch cadence, or failure tolerance. The control set must match platform support, business function, physical exposure, safety requirements, and the consequences of forced change.
Must Know
- Server requirements should cover supported operating systems, hardened images, endpoint detection, vulnerability management, privileged access, network exposure, patching, logging, backup, and decommissioning.
- Client and mobile designs combine enrollment, configuration, compliance, endpoint protection, application controls, data protection, device risk, and conditional access.
- IoT and embedded requirements start with identity, inventory, secure provisioning, signed updates, least functionality, segmentation, telemetry, and an end-of-life plan.
- OT and ICS prioritize safety and availability; passive discovery, Purdue-aware segmentation, monitored remote access, maintenance coordination, and specialized Defender for IoT visibility reduce operational disruption.
- Security baselines provide a tested starting point but require staged rollout, compatibility validation, exceptions, drift monitoring, and version governance.
- Windows LAPS rotates and protects local administrator passwords, reducing reuse and lateral movement while requiring authorized retrieval, audit, and recovery design.
Compare and Distinguish
- Intune manages configuration and compliance; Defender for Endpoint supplies endpoint detection, response, vulnerability, and risk signals; Conditional Access can consume device state.
- IT endpoints often tolerate active scanning and rapid change, while OT may require passive monitoring and carefully scheduled controls to protect safety and uptime.
Scenario examples
- Scenario: Corporate laptops must block access when risky without duplicating posture logic. Think: use Defender for Endpoint risk integrated with Intune compliance and Conditional Access.
- Scenario: A refinery forbids active probes and unplanned controller restarts. Think: use passive Defender for IoT monitoring, segmentation, controlled vendor access, and maintenance-window remediation.
Exam traps
- Applying a workstation baseline unchanged to a domain controller or industrial device can create new operational risk.
- LAPS addresses local administrator credential reuse; it does not govern domain administrator or service-account privilege.
Key takeaways
- One endpoint baseline can state common outcomes without forcing one implementation.
- IoT security depends on identity and lifecycle as much as telemetry and segmentation.
- For OT, passive evidence and controlled access take priority over disruptive discovery.
How it works
- Management platforms apply configuration and compliance state, endpoint protection detects behavior, and identity policy uses device signals to govern access.
- OT sensors observe industrial protocols and asset behavior without requiring disruptive scans of fragile controllers.
Objects and administrative surfaces
- Intune configuration, compliance, endpoint-security, update, and application policies; Defender device inventory, alerts, vulnerabilities, and response actions.
- Defender for IoT sensors, OT network maps, IoT identities, firmware provenance, Windows LAPS policies, password stores, and retrieval audits.
When to use it
- Use class-specific baseline families whenever endpoint capabilities, ownership, or operational consequences materially differ.
Security and governance implications
- Require baseline version owners, compatibility rings, exception expiry, device ownership, and unsupported-platform retirement plans.
Troubleshooting signals
- If compliant devices remain blocked, inspect signal latency, enrollment identity, policy conflicts, and Conditional Access targeting.
- If OT visibility has blind spots, validate sensor placement, mirrored traffic, encrypted protocols, asset zones, and vendor paths.
More detail
- Specify server and client requirements across platforms.
- Design IoT and OT safeguards with lifecycle and safety constraints.
- Evaluate security baselines and Windows LAPS within a broader privileged-access plan.
Ready for the quiz?
- Which server controls should be image-time versus runtime?
- Why can passive monitoring be decisive for an OT network?
- What risk remains after deploying Windows LAPS?
Related objectives
- D3.2.S1 — Specify security requirements for servers, including multiple platforms and operating systems
- D3.2.S2 — Specify security requirements for mobile devices and clients, including endpoint protection, hardening, and configuration
- D3.2.S3 — Specify security requirements for IoT devices and embedded systems
- D3.2.S4 — Evaluate solutions for securing operational technology (OT) and industrial control systems (ICS) by using Microsoft Defender for IoT
- D3.2.S5 — Specify security baselines for server and client endpoints
- D3.2.S6 — Evaluate Windows Local Administrator Password Solution (Windows LAPS) solution