Topic starter
28/09/2026 4:05 pm
TL;DR: CMMC Level 2 audit logging on Linux hinges on auditd rules that create, retain, and protect records for logons, identity changes, privileged commands, and audit configuration access, according to LinuxGuard. The real governance issue is not whether auditd is installed, but whether the host can produce attributable, tamper-resistant evidence an assessor can trust.
NHIMG editorial: based on content published by LinuxGuard: What Does CMMC Require of Linux Audit Logs?
Questions worth separating out
Q: What breaks when Linux auditd is installed but the ruleset is too small for CMMC?
A: A minimal auditd setup creates the appearance of logging without the evidence depth CMMC expects.
Q: Why does CMMC care so much about Linux audit log attribution and retention?
A: Because the control is meant to support investigation and reporting, not just storage.
Q: What are the most common Linux CMMC audit logging failures?
A: The recurring failures are predictable: auditd runs with a sparse ruleset, root activity is not tied back to the initiating user, audit failure is not detected, logs remain local and editable, and the documented configuration drifts from the live estate.
Practitioner guidance
- Expand the auditd ruleset to cover CMMC-relevant events Capture logons, failed access, privilege escalation, identity file changes, sudoers modifications, and access to audit configuration and audit logs.
- Use auid-based attribution for privileged commands Filter privileged execution so the audit trail links root actions back to the initiating user, not just to the escalated process.
- Ship audit logs off the Linux host Forward records to a protected central store that local administrators cannot edit or delete, and restrict who can manage that store.
What's in the full article
LinuxGuard's full article covers the operational detail this post intentionally leaves for the source:
- The exact auditd rules shown for logons, sudoers, credential files, and audit trail access.
- The retention and protection considerations behind off-host log shipping and immutable settings.
- The CMMC-to-NIST SP 800-171 mapping that assessors will expect to see in the SSP.
- The common implementation gaps that cause Linux audit evidence to fail during assessment.
👉 Read LinuxGuard's guide to CMMC audit log requirements on Linux →
CMMC on Linux audit logs: are your auditd controls sufficient?
Explore further
28/09/2026 4:07 pm
Auditability on Linux is a governance evidence problem, not a logging problem: CMMC Level 2 is testing whether the organisation can prove activity, not just record noise. On Linux, that means the audit trail has to be attributable, protected, and reviewable across the systems that store or process CUI. The practical conclusion is that auditd configuration, retention, and off-host protection are part of control design, not afterthoughts.
A question worth separating out:
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.
👉 Read our full editorial: CMMC audit log requirements on Linux: what assessors test
