Access Control 3.1.7 (3.1.7)

Does your organization use separate accounts for administrative tasks versus regular work activities?

Are regular user accounts prevented from installing software, changing security settings, or creating new accounts?

What exactly are privileged functions that need to be protected and logged?

Privileged functions are administrative or security-critical operations that can significantly impact system security or integrity. Examples include creating or modifying user accounts, changing security configurations, installing software, performing system backups or restores, managing encryption keys, modifying audit settings, accessing sensitive data repositories, and conducting system integrity checks. The specific privileged functions vary by system type and should be documented in your system security plan.

Does this control require that we eliminate all administrative access for regular users?

Yes, non-privileged users should not have the ability to execute privileged functions. Regular users should operate with standard user accounts that have only the permissions necessary for their job functions. When administrative tasks are needed, users should either request assistance from authorized administrators or use a separate privileged account (if authorized) that is logged and monitored. The goal is to prevent both intentional and accidental misuse of privileged functions.

Is it sufficient to log when someone logs in with a privileged account, or do we need to log each privileged action?

You must log the actual execution of privileged functions, not just authentication to privileged accounts. Simply logging that an administrator logged in does not satisfy this control. The audit logs must capture what privileged functions were executed, by whom, when, and the result. This granular logging enables detection of specific misuse or unauthorized actions even by legitimately authenticated privileged users.

How do we handle situations where users need temporary administrative access to perform their jobs?

Temporary administrative access should be managed through formal processes such as privilege elevation workflows, just-in-time access provisioning, or privileged access management (PAM) solutions. The key requirements are that the elevation is logged, time-limited, justified, and ideally requires approval. Users should not maintain persistent administrative privileges. All privileged functions executed during the temporary elevation must be logged with the individual user's identity, not a shared account.

What should we do if our legacy systems cannot technically enforce privilege separation or logging?

Legacy systems that cannot meet this control represent a compliance gap that must be addressed through a Plan of Action and Milestones (POA&M). Document the specific technical limitations, implement compensating controls where possible (such as network isolation, enhanced monitoring, or restricted access), and establish a timeline for remediation through system upgrades, replacements, or migration. Compensating controls alone may not be sufficient for CMMC certification depending on the assessor's evaluation and the system's role in protecting CUI.

Do cloud services and SaaS applications need to comply with this control?

Yes, if cloud services or SaaS applications process, store, or transmit CUI, they must comply with this control. You must ensure that non-privileged users cannot execute administrative functions in these platforms and that all privileged operations (such as user management, security configuration changes, or data exports) are logged. This typically involves configuring role-based access control in the cloud/SaaS admin console and enabling audit logging features, then exporting those logs to your centralized logging infrastructure for retention and monitoring.