One of the simplest requirements in CMMC is also one of the most misunderstood.
Control 3.1.1 says:
Organizations must “limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).” - CMMC Assessement Guide. Page 14
Straightforward, right? Yet, this is a control where many organizations trip up—not because of technology, but because of ownership.
This control falls clearly on the OSC. The responsibility for identifying who is authorized to use your systems belongs to your organization, not your service provider, not your consultant, and not Entra ID.
When we assess this control, the first objective we review is simple:
Determine if authorized users are identified.
That means we’re looking for an organizational process, not a technical configuration, that defines how users become “authorized.”
We want to understand how your company determines who gets access in the first place. Who makes that decision? Where is it documented? Is it consistently applied across your workforce?
During an assessment, we might ask questions like:
Your answers shouldn’t rely on your MSP’s systems or your IT tools. They should reflect your organizational process.
One of the most common errors we see is this:
“Entra ID identifies authorized users.”
That’s not accurate. Entra ID—or any identity management platform, can only enforce access for users who already exist in your system. It can require passwords, MFA, and conditional access policies. But it doesn’t determine who should have an account to begin with.
That decision is made by your organization, typically through your onboarding and offboarding processes.
Most companies handle this through HR. When a new employee is hired, their supervisor completes a form or checklist requesting access to specific systems or data, often by role (role-based access). HR or IT then creates an account based on that authorization. The form gets signed, stored, and possibly referenced later when there are personnel changes, like promotions or terminations.
That process- documented, approved, and repeatable- is how you identify authorized users.
It might not seem “technical,” but from a C3PAO perspective, this is where cybersecurity maturity begins: the human decision to control who’s in and who’s out.
As a leader, your role isn’t to configure the system; it’s to ensure the process exists, is understood, and is followed.
Here’s what good looks like during an assessment:
It’s not enough for IT to say, “We disable accounts when HR tells us.” The assessor will ask how HR communicates that, and where it’s recorded. They may ask to see an example as evidence.
If multiple providers are involved, for instance, your MSP manages Active Directory while HR handles onboarding, your Shared Responsibility Matrix (SRM) should reflect that division. The OSC identifies authorized users; the MSP enforces access controls.
That distinction matters, because during an assessment, the assessor is verifying that each party is performing its role exactly as defined in the SRM.
Controls like 3.1.1 may seem basic, but they build the foundation for every other access control requirement. If your process for identifying users isn’t documented and repeatable, your technical safeguards lose meaning.
Cybersecurity isn’t just about technical configs and encryption, it’s about people creating policies and following process. Knowing who’s authorized, how they’re approved, and how they’re removed is one of the most important leadership responsibilities in compliance. Risk controls are in place to manage the human risk factor and minimize the probability for security incidents.
Take a moment today to look beyond your technology stack and into your business and operations processes. Ask yourself:
If your team can answer these confidently, and back it up with documentation, you’re already ahead of many organizations.
And when your C3PAO asks, you won’t be pointing to your IT provider. You’ll be pointing to your own policy.