CMMC Level 2 Endpoint Encryption and MFA. The certificate evidence your C3PAO inspects.
An endpoint platform mapped control-by-control to the NIST SP 800-171 requirements your C3PAO will inspect, backed by active FIPS 140-3 certificates, multi-user Pre-Boot Authentication, phishing-resistant MFA for privileged access, and removable media encryption.
NIST SP 800-171 Control Coverage: What WinMagic Maps to Your C3PAO Assessment
SecureDoc and MagicEndpoint contribute to NIST SP 800-171 controls across the AC, AU, IA, MA, MP, PE, and SC families. The 13 rows below are the direct mappings where WinMagic is the primary technical mechanism your C3PAO will inspect. Download the full WinMagic + CMMC mapping for every control across both products.
| Control | What it requires | What WinMagic does |
|---|---|---|
| System & Communications Protection (SC) | ||
| SC.L2-3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. | WinMagic's cryptographic module is FIPS 140-3 validated by NIST, certificates #5204 and #5214. SecureDoc uses it to encrypt CUI at rest on endpoints and removable media. MagicEndpoint uses the same module for authentication. |
| SC.L2-3.13.16 | Protect the confidentiality of CUI at rest. | SecureDoc full-disk encryption protects CUI at rest on Windows, macOS, and Linux endpoints using the FIPS 140-3 validated module. Encryption keys are held in your SecureDoc management console. |
| SC.L2-3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. | SecureDoc File Encryption encrypts CUI at the file and folder level, so protected ciphertext crosses the network during transfers, uploads, or email attachment workflows. |
| Identification & Authentication (IA) | ||
| IA.L2-3.5.3 | Use multifactor authentication for privileged access and network access. | MagicEndpoint provides phishing-resistant MFA for privileged and non-privileged users. SecureDoc Pre-Boot Authentication supports PIV smart card, hardware token, Bluetooth-paired phone with biometrics, or password. |
| IA.L2-3.5.4 | Employ replay-resistant authentication mechanisms. | MagicEndpoint sign-in is tied to the specific network session and device-bound credential, reducing replay risk across privileged and non-privileged access. |
| IA.L1-3.5.1 | Identify users, processes acting on behalf of users, and devices. | SecureDoc identifies the user before the operating system starts. MagicEndpoint identifies the device using a TPM-anchored credential. |
| IA.L1-3.5.2 | Authenticate identities before allowing access. | SecureDoc verifies the user before the disk decryption key unlocks. MagicEndpoint verifies the device's TPM-bound identity before granting access to the identity provider. |
| Media Protection (MP) | ||
| MP.L2-3.8.6 | Protect CUI stored on digital media during transport. | SecureDoc RMCE encrypts CUI on USB drives, external storage, and CD/DVD media using AES 256-bit, with keys managed centrally in SecureDoc. |
| MP.L2-3.8.7 | Control the use of removable media. | On Windows endpoints, SecureDoc Port Control blocks any USB device not on the whitelist from being used. |
| MP.L2-3.8.8 | Prohibit portable storage devices with no identifiable owner. | Whitelisted removable devices are registered to a user or group, with Key Labels linking each key to its owner. RMCE logging records per-user identity for files written to managed media. |
| Audit & Accountability (AU) | ||
| AU.L2-3.3.1 | Create and retain audit logs for monitoring, investigation, and reporting. | SecureDoc captures sign-in events, key recovery actions, and policy changes. Reports on users, devices, keys, and groups can be exported as CSV, XLSX, or PDF. |
| AU.L2-3.3.2 | Trace individual user actions to specific users. | Audit records carry the actual user who signed into the endpoint and service provider, giving the assessor named user accountability. |
| Physical Protection (PE) | ||
| PE.L2-3.10.6 | Enforce safeguarding measures for CUI at alternate work sites. | SecureDoc encryption and MagicEndpoint sign-in protection run on the device itself, so controls apply in the office, at home, at customer sites, and while traveling. |
Control families covered: SC, IA, MP, AU, PE. The assessor determines compliance against your documented evidence. This table shows the artefacts SecureDoc and MagicEndpoint contribute.
Why Pre-Boot Authentication Is Required for CMMC Endpoint Compliance
FIPS-validated cryptography and pre-boot authentication work together. The cryptography keeps the data confidential on the disk. The authentication ensures the disk only unlocks for a verified user. Together, they give your CMMC posture both controls, the cryptography your assessor inspects, and the access control that travels with the device.
TPM-only disk encryption bypass
A publicly disclosed vulnerability in BitLocker, YellowKey, CVE-2026-45585, bypasses default TPM-only disk encryption configurations through the operating system's recovery environment. Physical access and a USB stick are sufficient to unlock the disk. The vendor's published mitigation: switch from TPM-only to TPM with PIN, or disable the recovery environment.
TPM-only authenticates the machine, not the user
Default disk encryption configurations on most systems release the disk decryption key based on the machine's hardware state, no user identity required. The configuration depends on no vulnerability appearing in the boot path, recovery environment, or TPM communication channel. Strong encryption alone doesn't close those surfaces.
User identity before the disk unlocks
SecureDoc Pre-Boot Authentication makes user identity the precondition for releasing the disk decryption key. Multi-user PBA, every user with their own credentials, not a shared PIN. PIV smart card, hardware token, Bluetooth phone, or password at pre-boot on Windows and Linux; on macOS the disk is protected through managed FileVault, all from one console.
Federal Standards Behind CMMC Level 2: NIST 800-171, FIPS 140-3, and DFARS
Request a CMMC Readiness Briefing with a WinMagic Specialist
A short briefing with a WinMagic specialist. We bring the certificate references, current NIST FIPS 140-3 module status across the FDE market, and a control-by-control read against your CUI boundary. You bring the environment.
- Control-by-control mapping to NIST 800-171 / 800-172 in your CUI boundary.
- FIPS 140-3 module status read across the endpoint cryptography market.
- Deployment fit for Windows, macOS, Linux, and removable-media environments.
- Path through Carahsoft or direct purchase.
CMMC endpoint security questions.
Does WinMagic have FIPS 140-3 validation?
Yes. WinMagic holds active FIPS 140-3 certificates #5204, Windows, and #5214, macOS and Linux. These are the certificate numbers a C3PAO assessor inspects for SC.L2-3.13.11 compliance.
What NIST SP 800-171 controls does SecureDoc cover?
SecureDoc maps to 39 controls across the SC, IA, MP, AU, and PE families of NIST SP 800-171. MagicEndpoint maps to an additional 25 controls covering IA and AU requirements.
What is pre-boot authentication and why does CMMC require it?
Pre-boot authentication, PBA, requires a user to verify their identity before the operating system starts and the disk decryption key is released. CMMC Level 2 requires it because TPM-only disk encryption, the BitLocker default, authenticates the machine, not the user, which leaves the recovery environment as an attack surface.
What is the difference between CMMC Level 2 and Level 3 for endpoint encryption?
CMMC Level 2 maps to the 110 controls in NIST SP 800-171 and requires a C3PAO third-party assessment. Level 3 adds enhanced controls from NIST SP 800-172 and requires a government-led assessment. WinMagic's FIPS 140-3 validated stack supports both levels.
When do FIPS 140-2 modules expire for CMMC assessments?
FIPS 140-2 modules move to NIST's Historical List on September 21, 2026. CMMC Level 2 C3PAO assessments begin November 10, 2026. Contractors using FIPS 140-2 modules after that date may not satisfy SC.L2-3.13.11.