Use non-privileged accounts or roles when accessing nonsecurity functions
📖 What This Means
This control means that employees should use standard user accounts (not admin or privileged accounts) for everyday tasks like checking email, browsing the web, or using office software. Privileged accounts with higher access rights should only be used when absolutely necessary, such as when installing software or changing system settings. This reduces the risk of accidental or intentional misuse of powerful accounts. For example, if an employee's standard account gets hacked while checking email, the attacker won't automatically gain access to sensitive systems. Another example: An engineer should use a regular account to write reports, switching to an admin account only when needed to update engineering software.
🎯 Why It Matters
Using privileged accounts for daily work significantly increases security risks. If compromised, these accounts can give attackers full control of systems, leading to data breaches or system damage. A 2022 Verizon report showed 80% of breaches involved privilege abuse. The DoD requires this control because a single compromised admin account could expose sensitive defense contracts (CUI). A real-world example: In 2020, a defense contractor's employee used an admin account to check email, resulting in a ransomware infection that spread across their entire network, costing $4.2 million in recovery. CMMC enforces this to prevent such scenarios by limiting privileged access.
✅ How to Implement
- 1. In AWS/Azure/GCP, create separate IAM roles for admin vs. regular users
- 2. Configure Conditional Access Policies (Azure) or IAM Boundaries (AWS) to enforce role separation
- 3. Set up Just-In-Time access solutions like Azure PIM or AWS IAM Access Analyzer
- 4. Enable logging for all role assumption events in CloudTrail (AWS) or Activity Logs (Azure)
- 5. Tag resources to prevent non-admin users from accessing sensitive services
- 6. Use service control policies (AWS) or management groups (Azure) to enforce account separation
- 7. Implement session recording for privileged access (e.g., Azure Bastion or AWS Session Manager)
📋 Evidence Examples
Account Role Assignment Policy
Screenshot of IAM Roles
Privileged Session Logs
User Access Training Records
UAC/GPO Configuration
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L2-3.1.6 ("Use non-privileged accounts or roles when accessing nonsecurity functions"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L2-3.1.6 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to use non-privileged accounts or roles when accessing nonsecurity functions. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"AC.L2-3.1.6 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to use non-privileged accounts or roles when accessing nonsecurity functions. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L2-3.1.6 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where use non-privileged accounts or roles when accessing nonsecurity functions applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L2-3.1.6
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do all users have separate standard and privileged accounts?
Question 2: Are privileged accounts restricted to specific workstations/services?
Question 3: Is there logging of all privileged account usage?
Question 4: Do policies prohibit using privileged accounts for email/web?
Question 5: Are quarterly reviews conducted of privileged access?
⚠️ Common Mistakes (What Auditors Flag)
1. Shared admin accounts
2. No logging of privilege elevation
3. Documentation doesn't match actual access
4. Cloud admins using root accounts daily
5. No justification for privileged access
📚 Parent Policy
This practice is governed by the Access Control Policy