Access Control 3.1.2 (3.1.2)
Limit system access to the types of transactions and functions that authorized users are permitted to execute.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to restrict what users can do within systems based on their job roles and responsibilities. It's not enough to just control who can log in - you must also control what actions they can perform once logged in. For example, a regular employee might be able to view customer records but not delete them, while a manager might have deletion rights. This prevents users from accidentally or intentionally performing actions outside their authorized duties.
Control Intent
Prevent unauthorized or inappropriate actions within systems by ensuring users can only perform functions necessary for their legitimate job duties, thereby reducing the risk of accidental or malicious misuse of system capabilities.
Who This Control Applies To
- •All systems that process, store, or transmit CUI
- •Applications with role-based access control requirements
- •Databases containing CUI
- •Administrative interfaces and privileged functions
- •Systems with multiple user types or permission levels
- •Cloud services and SaaS applications handling CUI
- •Network devices and infrastructure components
- •Development and production environments
Not Applicable When
- •Single-user systems with no network connectivity and no CUI access by others
- •Systems where all users require identical full administrative access by documented business necessity
- •Standalone systems used by a single authorized individual with no shared access
- •Systems in scope only for physical security controls with no logical access
Key Objectives
- 1Restrict user access to only those system functions and transaction types that are necessary for their authorized job responsibilities.
- 2Prevent users from executing privileged or sensitive operations beyond their defined role or authorization level.
- 3Reduce the attack surface and potential for insider threats by limiting the scope of actions any single user can perform.
Sample Self-Assessment Questions (Partial)
Does your system have different types of user accounts (e.g., regular users, administrators, read-only users)?
Can you describe what actions different user roles are allowed to perform in your system?
Implementation Approaches (High-Level)
Role-Based Access Control (RBAC) with Function Mapping
Define distinct roles based on job functions and map specific system functions and transaction types to each role. Users are assigned roles, and the system enforces function-level restrictions based on role membership.
Attribute-Based Access Control (ABAC) for Function Authorization
Use user attributes, resource attributes, and environmental conditions to dynamically determine whether a user can execute a specific function. This provides more granular control than pure role-based approaches.
Privileged Access Management (PAM) for Administrative Functions
Separate and strictly control access to privileged functions through dedicated PAM solutions that provide just-in-time access, session monitoring, and approval workflows for high-risk operations.
Application-Level Function Authorization with Separation of Duties
Implement function-level access control within applications with explicit separation of duties controls to prevent any single user from completing sensitive end-to-end processes alone.
API Gateway with Function-Level Authorization
Centralize function-level access control at an API gateway that validates user permissions before routing requests to backend services, ensuring consistent enforcement across all system interfaces.
Database-Level Function Restrictions
Enforce function-level access control at the database layer using database roles, permissions, and stored procedures to restrict what operations users can perform on data.
Time-Based and Context-Aware Function Restrictions
Implement additional function-level restrictions based on time of day, day of week, location, device type, or other contextual factors to limit when and how users can execute sensitive functions.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If function-level access control is not implemented, prioritize high-risk functions first (e.g., administrative functions, data deletion, financial transactions, configuration changes) Document current state: which systems lack function-level controls and what risks this presents Define target state: role definitions, function mappings, and enforcement mechanisms For commercial software, investigate whether RBAC or function-level controls are available but not configured For custom applications, plan code changes to implement authorization checks at function level Consider implementing compensating controls while remediating: enhanced monitoring, approval workflows, separation of duties through process controls Establish interim milestones: implement controls for most critical functions first, then expand coverage Include testing and validation in the remediation plan to ensure controls work as intended Plan for ongoing maintenance: periodic role reviews, permission recertification, policy updates If technical implementation is not feasible for certain systems, document why and implement procedural compensating controls with evidence of consistent enforcement Consider whether system replacement or significant redesign is more cost-effective than retrofitting controls into legacy systems
Frequently Asked Questions
What is the difference between 3.1.1 (limit system access to authorized users) and 3.1.2 (limit access to authorized functions)?
3.1.1 focuses on authentication - controlling WHO can access the system. 3.1.2 focuses on authorization - controlling WHAT authenticated users can do once they're in the system. You need both: 3.1.1 ensures only authorized people can log in, and 3.1.2 ensures those people can only perform actions appropriate to their role. Think of 3.1.1 as the front door lock and 3.1.2 as locks on individual rooms inside the building.
Do I need to implement this control if all my users have the same job function and need the same access?
If all users legitimately require identical access to all functions, you may have limited applicability, but this is rare. Most systems have at least some administrative functions that should be restricted to administrators only. Even in small organizations, not everyone should be able to delete data, modify system configurations, or perform other high-risk operations. You should document why all users require identical function access if claiming limited applicability.
Is it enough to hide buttons or menu items from users who shouldn't access certain functions?
No, hiding UI elements is not sufficient. Users with technical knowledge can bypass UI restrictions by directly calling APIs, manipulating URLs, or accessing databases. Function-level access control must be enforced at the backend - in your application logic, API layer, and database layer - not just in the user interface. UI restrictions are helpful for usability but do not satisfy this control's security requirements.
How is this control verified during a CMMC assessment?
Assessors will ask for documentation of your roles and what functions each role can perform. They will then test the system by attempting to execute unauthorized functions with different user accounts. They'll look for evidence in system configurations, code, or database permissions that function restrictions are technically enforced. They'll also review audit logs to see if unauthorized function attempts are being blocked and logged. Simply having a policy is not enough - you must demonstrate technical enforcement.
What should I do if my commercial software doesn't support role-based function restrictions?
First, verify with the vendor whether RBAC features exist but are not configured. Many commercial systems have these capabilities but require setup. If the software truly lacks function-level controls, you have several options: implement compensating controls (enhanced monitoring, approval workflows, separation of duties through procedures), use an API gateway or proxy to add authorization controls, consider alternative software that meets requirements, or document this as a system limitation and create a POA&M with a remediation plan.
Do service accounts and automated processes need function restrictions too?
Yes, service accounts and automated processes should follow the principle of least privilege and only have access to the specific functions they need to perform. A backup service account should only have backup permissions, not full administrative access. An application service account should only be able to execute the specific database operations the application requires. Overly permissioned service accounts are a common finding in assessments and represent significant risk if compromised.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.