Foundational Architecture & Design

The Endpoint Security Boundary

Concept: Define what constitutes a "CMMC Endpoint."

Key Point: In a Zero Trust model, the device is the new perimeter. If it touches Controlled Unclassified Information (CUI), it must be managed.

The architecture applies the Microsoft Zero Trust model specifically to CMMC constraints:

• Verify Explicitly: Every device must prove its identity and health state (via Compliance Policies) before accessing CUI.
• Use Least Privilege Access: Users operate as Standard Users; local administrative rights are removed and managed via LAPS.
• Assume Breach: Configurations assume the network is hostile. Encryption (BitLocker) and Attack Surface Reduction (ASR) rules are enforced regardless of network location.

CMMC Context: This boundary enforces the distinction between an Authorized Device (Managed, Compliant, permitted to hold CUI) and an Unmanaged Device (Guest/Personal, blocked from CUI).

---

Configuration Architecture: The Open Intune Baseline (OIB)

Intune Best Practice

Concept: The strategy for enforcing security controls within the boundary using community-vetted, granular policies.

A critical design decision in this architecture is the exclusion of generic Microsoft Security Baselines in favor of the Open Intune Baseline (OIB). No one says it better than Intune MVP Jon Towles in his Intune Security Baselines: The Truth Behind the Chaos blog post.

While building hundreds of granular policies from scratch is operationally exhausting, OIB acts as a deployment accelerator. It aggregates frameworks like the CIS Benchmarks and Microsoft Best Practices into a unified set of modular JSON files designed explicitly for the Intune Settings Catalog and Endpoint Security blades.

Why OIB Outperforms Built-in Baselines in GCC High

Microsoft’s built-in baselines offer a "quick start" for commercial environments, but they introduce significant risks and friction in a regulated GCC High boundary:

1. Eliminating GCC High "Phantom Errors": Built-in baselines frequently include hardcoded telemetry and diagnostic data settings that attempt to communicate with commercial Microsoft endpoints. Because those endpoints are blocked in GCC High, the profiles sit in a perpetual "Error" state, ruining dashboard compliance reporting. OIB's modular nature allows administrators to surgically strip these settings out prior to deployment.
2. Version Lifecycle Stability: Updating a Microsoft baseline version is a destructive action that creates a completely new profile, forcing administrators to manually migrate years of custom exceptions. OIB relies on the Settings Catalog; when Microsoft adds new features, existing OIB profiles remain perfectly intact and version-stable.
3. Preventing "Tattooing" and Conflicts: Built-in baselines frequently overlap (e.g., both the Windows and Edge baselines configuring SmartScreen), causing device conflict errors. Furthermore, removing a built-in baseline often leaves the device "tattooed" with the restriction permanently. OIB is meticulously designed by the community to eliminate overlaps and cleanly revert when unassigned.
4. CMMC Defensibility: C3PAO assessors require a clear line of sight from a NIST 800-171 control to the technical mechanism enforcing it. Pointing an assessor to a modular, targeted OIB profile is significantly easier to audit and defend than a monolithic baseline containing 800 unrelated settings.

GCC High Feature Parity & Modification

OIB is designed for the commercial cloud. It must be modified prior to use in GCC High. Features relying on commercial-only APIs (such as Expedited Telemetry reporting) or commercial identity endpoints must be stripped or updated. The exact modifications required to overlay CMMC and GCC High requirements onto OIB are detailed in Chapter 10: Mobile & Endpoint Security.

---

Device Personas (The Decision Matrix)

Concept: Not all devices are treated equally. There are two archetypes.

Action: Refer to the Technical Decision Matrix for assignment criteria.

• The Knowledge Worker (1:1): * Assigned to a specific user (Faculty/Staff/Consultant).
  • Prioritizes User Experience, SSO, and Stability (Windows Autopatch).
  • Typical for: Primary workstations, laptops traveling with users.
• The Shared Workspace (1:Many): * Public labs, conference rooms, or kiosks.
  • Prioritizes Uniformity (Windows Update for Business) and Reset-ability (Shared PC Mode).
  • Typical for: Hot-desking environments, secure enclaves.

---

The Shift: Imaging vs. Provisioning

Concept: The death of the "Golden Image."

Key Point: The architectural shift from "Monolithic Imaging" (Ghost/SCCM) to "Modern Provisioning" (Autopilot).

Why: Instead of maintaining static images that decay immediately, we deploy a standard OEM image and layer configurations on top dynamically. This methodology is detailed in Section 9-3 Provisioning with Windows Autopilot.

---

Identity Architecture Strategy

Concept: High-level introduction to the "Join" types.

Key Point: The decision fork between Entra Join (Cloud-only) vs. Hybrid Join (Line of Sight).

• Entra Join (Cloud Only): The preferred modern standard. Eliminates dependency on on-premise Domain Controllers.
• Hybrid Join: Maintained only for legacy backward compatibility where direct line-of-sight to an on-prem DC is mandated by legacy applications.

Why: This sets up Section 9-4 (Cloud Only) and Section 9-5 (Hybrid), explaining how each architecture maps to the Personas defined above.

---

Hardware Prerequisites (CMMC & Windows 11)

Concept: The non-negotiable hardware floor for compliance.

Checklist:

• TPM 2.0: Required for BitLocker & Windows 11. (Critical for CMMC Identification and Authentication).
• UEFI / Secure Boot: Must be enabled to support device attestation.
• 64-bit Architecture: Required for modern Windows 11 support.
• Processor Compatibility: Must support Virtualization-Based Security (VBS) for features like Credential Guard.