Comparing alternative patterns for the same objective
Two examples can both satisfy the same assessment objective and look nothing alike. That is normal. What is not normal is pretending the control catalog will tell you which pattern is “correct” for your boundary.
This article walks a concrete comparison using published ControlVerdict examples, then gives a reusable framework so you can do the same for any contested practice.
The objective, not the brand
Start from the assessment objective language, not from the product name on the invoice. For multifactor authentication under CMMC Level 2, IA.L2-3.5.3 breaks into discrete determinations: privileged accounts identified; MFA for local access to those accounts; MFA for network access to those accounts; MFA for network access to non-privileged accounts. A practice is MET only when every applicable objective is satisfied.
Cloud Conditional Access that covers SaaS beautifully can still leave local privileged console open. An on-prem smart-card design that nails the rack can still leave a SaaS admin blade password-only. Different failure modes, same control family.
Candidate A — On-prem smart card + RADIUS
Pattern: Smart card at the rack, RADIUS-gated MFA for VDI and VPN.
| Lens | Read |
|---|---|
| Core mechanism | PKI smart card (+ PIN) for privileged local/console; RADIUS for VDI/VPN and device admin |
| Environment fit | Deliberately on-prem CUI lab, limited cloud IdP use |
| Evidence class | Privileged inventory, smart-card policy, RADIUS exports, password-only rejection tests |
| Adequacy | Strong for local privileged and network MFA objectives when the boundary is the lab |
| Sufficiency risk | Cloud admin paths outside the lab; break-glass hypervisor shell called out as accepted gap |
Candidate B — Entra authentication + device claims
Patterns that often travel together:
- Nothing reaches the VDI pool without a verified user, workload, and device claim (IA.L2-3.5.2 authentication prerequisite)
- Enclave allow-list: users, service principals, and compliant devices only (AC.L2-3.1.1 — Conditional Access + Intune compliance)
| Lens | Read |
|---|---|
| Core mechanism | IdP authentication everywhere; compliant-device claims; legacy auth blocked |
| Environment fit | VDI/SaaS enclave, cloud-forward OSC |
| Evidence class | Conditional Access exports, device certificate / compliance grants, sign-in logs with device object IDs |
| Adequacy | Strong for network access and device-bound access to CUI apps |
| Sufficiency risk | Local privileged console MFA is a different objective — do not assume Conditional Access covers the rack |
Related least-privilege companion: Just-in-time admin roles; standing privilege only for break-glass (PIM + phishing-resistant MFA on activation).
Adequacy vs sufficiency (the comparison that matters)
When you rate — or when you decide which pattern to copy — separate two questions:
- Adequacy. Is this the right kind of evidence for the objective? Interview + config export + live demo is a different class than a policy PDF.
- Sufficiency. Is there enough? Coverage across every component where the requirement applies; enough operational history; exceptions documented rather than hoped away.
Candidate A and Candidate B can both be adequate for overlapping objectives and still leave different sufficiency holes. “Different but both valid” is the right read when each closes the objectives it claims inside its stated boundary. One pattern is simply stronger when the other silently skips an objective (classic: network MFA without local privileged MFA).
A skeleton you can reuse
- Quote the objective(s) you are comparing.
- List candidate examples with one-line mechanisms and links.
- Score adequacy and sufficiency separately.
- Note community / assessor divergence on each example.
- Decide: assemble both, pick one, or invent a third for your hybrid boundary.
Practical takeaway for small OSCs
If you are Microsoft 365 + Intune + Entra, start from Candidate B and explicitly add a plan for local privileged MFA (PAW, Windows Hello for Business, smart card, or equivalent). If you are lab-heavy and on-prem, start from Candidate A and explicitly cover any cloud admin plane that can still touch CUI or security protection data.
For a stack checklist, see Starter kit: Microsoft 365 + Intune + Entra.
Disclaimer
Comparisons here are community editorial, not assessment determinations. Match patterns to your scope, shared-responsibility matrix, and evidence you can sustain.
Discussion(0)
No discussion on this article yet
Ask clarifying questions or share related assessment scenarios.
Sign in to start a thread.