CMMC audit log requirements on Linux: what assessors test

At a glance

What this is: This is a CMMC-focused guide to Linux audit logging that argues auditd must generate, retain, and protect evidence for logons, identity changes, privileged commands, and audit configuration access.

Why it matters: It matters because assessors test whether Linux hosts can produce attributable, tamper-resistant audit evidence for CUI, which turns logging into a governance control rather than a compliance checkbox.

Context

CMMC Level 2 does not name an operating system, but the requirement lands on Linux because those hosts commonly store or process controlled unclassified information. The issue is not whether audit logging exists in principle, but whether the Linux estate can show a defensible audit trail tied to the CMMC and NIST SP 800-171 expectations.

On Linux, that means auditd has to record the activity that matters, preserve it long enough for investigation, and protect it from local tampering. The article frames this as an assessor test: can the environment produce evidence for who did what, where, and when across the hosts in scope?

Key questions

Q: What breaks when Linux auditd logs do not tie privileged actions to individual users?

A: The audit trail loses accountability. CMMC expects audit records that can be traced to an individual user, so shared root activity or missing auid linkage makes it impossible to show who actually performed the privileged action. The result is a log set that may look complete but cannot support an assessor's test of attribution.

Q: Why do Linux audit logs need to be reviewed as well as created for CMMC?

A: Because record creation alone does not prove the organisation can detect unauthorised activity. Review evidence shows that someone is actually examining the trail, and CMMC assessors can ask for that artefact. Without review outputs, the host may be logging correctly while the governance process still fails.

Q: What are the signs that a Linux auditd setup is too weak for CMMC?

A: Common warning signs are a near-empty default ruleset, no coverage for sudo or credential changes, local-only logs, no alert if auditd stops, and no dated review evidence. Any one of those gaps can leave the estate unable to prove that it can create, retain, and protect audit records for CUI systems.

Q: How should teams prove Linux audit logs are protected from tampering?

A: They should show that logs are shipped to a protected central store, that local admins cannot modify the authoritative copy, that audit configuration changes are themselves logged, and that immutable settings are enforced where appropriate. The proof is not a screenshot. It is configuration evidence, retention evidence, and review evidence together.

Technical breakdown

What CMMC expects from Linux audit logs

CMMC Level 2 inherits AU.L2-3.3.1 from NIST SP 800-171, which requires logs and records sufficient for monitoring, analysis, investigation, and reporting of unauthorised activity. On Linux, that expectation is operationalised through auditd, but only if the ruleset covers the events that actually matter: logons, privilege use, account and credential changes, and access to audit settings. The requirement is not satisfied by generic logging volume. It is satisfied when the host can produce attributable evidence that supports assessor review and incident reconstruction.

Practical implication: define your auditd baseline around the events assessors will test, not around whatever the default package configuration happens to log.

Why attribution and tamper resistance matter

CMMC audit evidence must be attributable to an individual user and protected from unauthorised modification or deletion. That is why the article emphasises auid-based attribution for privileged commands, watching /etc/sudoers and credential files, and shipping logs off the host. If local administrators can alter the audit trail, the record loses evidentiary value. If root activity is not tied back to the real user, the record cannot support accountability. In practice, the audit log is only useful when it survives both administrative drift and compromise.

Practical implication: use auid-based rules, immutable settings, and off-host collection so the audit trail remains credible under investigation.

How auditd rules turn activity into evidence

auditd works by matching kernel events and file changes against rules that emit records with enough context for later review. For CMMC, that includes watching authentication files, sudo configuration, and the audit directory itself, plus execve rules that capture privileged command execution. The article's example shows the logic: record both successful and failed activity, tie privileged actions to the initiating user, and protect the logging subsystem from changes. Without those rules, auditd may be present but the logs are too thin to prove compliance.

Practical implication: validate the rule set host by host and test whether it records the exact actions an assessor is likely to request.

Threat narrative

Attacker objective: The objective is to remove or degrade the audit evidence needed to prove who accessed CUI systems and what they did.

1. Entry occurs through normal administrative access to a Linux host that is in scope for CMMC and handling CUI.
2. Credential or privilege use is visible only if auditd captures identity changes, sudo activity, and executable command records tied to the real user.
3. Impact is loss of trustworthy evidence when audit logs are missing, incomplete, local-only, or editable by privileged users.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Linux audit logging for CMMC is an evidence problem, not an installation problem. The article makes clear that auditd can be present and still fail the control if the ruleset does not capture the events assessors expect to see. That is a governance failure because the control outcome is attributable, tamper-resistant evidence, not software presence. Practitioners should treat the Linux audit baseline as test evidence, not as a service status check.

Auditability on Linux depends on identity linkage, not just event capture. AU.L2-3.3.2 is the critical companion to AU.L2-3.3.1 because shared or unattributed activity destroys the value of the trail. When privileged commands, credential file changes, and sudo usage are not tied back to a real user, the organisation can collect logs and still fail accountability. The implication is that identity design and audit design have to be validated together.

Centralised log protection is the control boundary that makes Linux audit records usable. Local logs on a host that an administrator can edit or erase are operationally fragile even when the rules are technically correct. The article's emphasis on off-host shipping, immutable settings, and watched audit directories shows where the control really lives. The practitioner conclusion is simple: if the host can rewrite its own evidence, the assessor will not trust the evidence.

Audit review cadence is part of the control, not a postscript. Creating records without a defined review process only proves that the system can emit logs, not that the organisation can detect unlawful or unauthorised activity. The article points to recorded review activity as artefacts a C3PAO can inspect, which makes review evidence a first-class governance object. Teams should measure whether review output exists, is dated, and is mapped to the in-scope Linux estate.

Attribute to the real user, or the Linux trail becomes non-compliant by design. The practical use of auid in privileged command logging is the difference between evidence of root activity and evidence of human accountability. That distinction matters because CMMC asks whether the organisation can trace activity to an individual user. The practitioner takeaway is that Linux audit logging must be designed around accountability, not around raw command volume.

What this signals

Audit evidence on Linux is only as strong as the identity linkage behind it: if privileged commands cannot be traced back to the initiating user, the control outcome collapses into a generic system record with little assessment value. Teams should validate that their audit trail supports accountability at the user level, not just at the host level.

CMMC pushes Linux teams to treat logging as a governed evidence chain. That means the generation of records, the retention promise in the SSP, the immutability of the audit subsystem, and the review artefacts all have to line up before an assessor will trust the result.

For practitioners

• Build a CMMC-specific auditd baseline Cover logons, failed logons, identity and credential file changes, sudo configuration, privileged command execution, and access to the audit directory on every in-scope Linux host.
• Attribute privileged activity to the real user Use auid-based execve rules so privileged commands can be tied back to the initiating account rather than only to root, and verify that shared logins are not masking accountability.
• Ship audit logs off the host Forward records to a protected central store that local administrators cannot alter, delete, or truncate, and confirm the storage location matches the retention period in the SSP.
• Make auditd immutability part of the control test Set rules to immutable mode where appropriate and confirm that changes require a reboot that is itself logged, so the logging subsystem cannot be rewritten silently.
• Evidence the review process Keep dated review outputs that show someone examined the audit trail on a defined schedule and that the review covered the Linux hosts in scope for CUI.

Key takeaways

• Linux audit logging for CMMC fails when teams treat auditd as installed software instead of an evidence-producing control.
• The article ties compliance risk to attribution, retention, and tamper resistance, especially where privileged activity must be linked to an individual user.
• A defensible Linux audit posture depends on off-host log protection, immutable configuration, and documented review of the records produced.

Key terms

• Auditd: Auditd is the Linux audit subsystem used to record system events such as file changes, command execution, and authentication-related activity. In privileged access environments, it provides detailed evidence, but the rules must be scoped carefully so the resulting logs remain reviewable and operationally useful.
• Audit Login Uid (Auid): The audit login uid is the identifier used to tie privileged actions back to the original user session. On Linux, it matters because root can execute the command, but auid identifies who initiated it, which is essential for accountability, investigation, and CMMC audit evidence.
• Auditing and Accountability: Auditing and accountability are the controls that make access and privilege changes visible, traceable, and reviewable. In CJIS environments, they require reliable logs for login attempts, permission changes, privileged actions, and tamper attempts, so investigators and auditors can reconstruct what happened with confidence.
• C3PAO: A C3PAO is a Certified Third-Party Assessor Organisation that evaluates whether an organisation meets CMMC requirements. Its role is to validate implementation through documentation, interviews, and testing, which means organisations must be able to demonstrate controls rather than simply describe them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.