OMB M-21-31 Logging Maturity Guide: EL0 to EL3

Most organisations cannot answer a simple incident question, "what did this account do on this host 14 months ago?", because the logs were never collected, were kept for 90 days, or cannot be correlated. OMB Memorandum M-21-31, issued on 27 August 2021 under section 8 of Executive Order 14028, answered that question for US federal agencies with a four-tier event logging maturity model, EL0 to EL3, plus minimum log fields, retention periods and log categories. This guide explains each tier, the deadlines the memo set, how it is enforced, and how private sector teams can reuse it as a logging baseline. It is for SOC leads, logging architects and federal contractors. Status of the memo as published was checked on 27 October 2026 on the White House archive; for log management practice in general see the NIST SP 800-92 Log Management Guide.

Key takeaways

• Four tiers, defined by log criticality: EL0 Not Effective, EL1 Basic (highest criticality logs), EL2 Intermediate (intermediate criticality added), EL3 Advanced (all criticality levels).
• The deadlines were aggressive: assess within 60 days, reach EL1 within one year, EL2 within 18 months and EL3 within two years of the memo.
• Retention is long by commercial standards: Appendix C sets typical minimums of 12 months in active storage and 18 months in cold storage, and 72 hours for full packet capture.
• EL1 is more than collection: it requires minimum log fields, a common time standard, near real-time forwarding, cryptographic log protection, passive DNS and log access for CISA and the FBI.
• EL3 explicitly covers non-user accounts: user behaviour monitoring must cover "all user and non-user accounts", which brings service accounts and other non-human identities into scope.

Scope: who and what is covered

M-21-31 applies to agencies as defined in 44 U.S.C. 3502 and their Federal information systems, including on-premises systems and connections hosted by third parties such as cloud service providers. It does not apply to national security systems. Contractors are reached indirectly: the memo expects software developed for agencies to log the required data, such as event identifiers and timestamps, and contractors operating infrastructure for agencies to forward phishing attempts to CISA. Section III gives CISA a role advising agencies on logging assessments and developing assessment tools with the FBI, and asks the Department of Commerce to maintain NIST SP 800-92 with CISA and the FBI and fold the memo's requirements into the next revision.

For private sector organisations the memo has no legal force, but it is one of very few public documents that specifies what to log, which fields to capture and how long to keep it, which is why it is often adopted as a logging baseline in contracts and internal standards.

Key obligations

The maturity model (Table 1)

Requirements by tier (Appendix A)

Minimum logging data

Each event log should include, where applicable, an accurate timestamp, status code, device identifier, session identifier, source and destination IP addresses (IPv4 and IPv6) and the username. The memo asks for key-value pairs and unique event identifiers where possible. These fields are what make correlation across sources possible; without a session identifier and a reliable username, a SIEM can collect everything and still fail to tell the story of one session. See the Secure Logging Vocabulary and Application Security Events Guide.

• Time: consistent, standard timestamps in UTC, with an authoritative time source as the baseline. See the NTP Security Guide.
• Passive DNS: log DNS queries, including encrypted DNS, with analytics able to identify the source host of each query. See the DNS Logging and Detection Guide.
• Protection: logs protected cryptographically against tampering and unauthorised access, access limited to staff with a job-related need, monitoring for logging disruption, prompt backup and integrity checks against log hashes.

Retention (Appendix C)

The memo frames these as minimums; agencies may keep data longer. Appendix C also lists the log categories, grouped into identity, credential and privileged identity management; email filtering and reputation; network infrastructure (DHCP, DNS, SNMP, firewalls, VPNs, routers and switches, load balancers, proxies, IDS/IPS); operating systems (Windows, macOS, BSD and Linux); cloud environments; authentication and authorisation; anti-malware; vulnerability assessment; PKI; database and application logs; virtualisation; mobile device management; containers; mainframes; and network traffic. For cloud and SaaS sources, check licence tiers, because many default audit log retention periods are far shorter than 12 months. See the SaaS Audit Log Retention and Licensing Guide.

Timeline and current status

All original deadlines have passed. When checked on 27 October 2026 the memo was available on the White House archive site rather than the current whitehouse.gov, and executive orders on federal cybersecurity have been amended since 2021. Confirm with OMB or your agency CIO whether later memoranda have changed reporting on M-21-31 before relying on it as a current mandate; the technical content remains a sound baseline either way.

Enforcement and penalties

There are no fines. M-21-31 is an OMB memorandum binding on executive agencies, enforced through OMB oversight of agency plans and budgets: agencies had to submit their assessments, resourcing and implementation gaps to the OMB Resource Management Office and their OFCIO desk officer, and provide logs to CISA and the FBI on request. Contractors feel it through contract clauses that pass the logging requirements down. For private organisations the consequences are indirect: a regulator, insurer or court asking why an incident could not be scoped will compare your logging to published baselines like this one.

What it means for AI agents and non-human identities

The memo is unusually explicit about machines. Its first log category is identity, credential and privileged identity management, and EL3 requires user behaviour analytics across "all user and non-user accounts", detecting at minimum compromised credentials, privileged user compromise, improper asset access, compromised hosts and lateral movement.

• Service principals and app credentials: in the SolarWinds compromise, attackers forged SAML tokens and added credentials to existing application service principals to read mail as trusted apps. Logging credential additions to applications and token issuance is exactly the identity category Appendix C calls for.
• Username field for machines: the minimum logging data asks for a username. For workloads that means a distinct workload identity per service, not a shared account, or the field carries no evidential value. See the Non-Human Identity (NHI) Guide.
• AI agents: agent actions should log the agent identity, the human principal on whose behalf it acted, the tool called and the session identifier, so that the EL1 fields still answer "who did what".
• Behaviour baselines: non-human accounts have stable patterns, which makes UEBA more effective for them than for people. See the UEBA Guide.

Compliance steps

1. Inventory log sources against the Appendix C categories and assign each a criticality level.
2. Score current state per requirement in the Appendix A table; your tier is the lowest tier where every requirement is met.
3. Fix the fields first: timestamp in UTC from an authoritative source, device and session identifiers, source and destination IP, username. Bad fields make every later tier worthless.
4. Forward and protect: near real-time, encrypted forwarding to the SIEM or data lake, with hash-based integrity checks and restricted admin access. See the SIEM Guide.
5. Set retention tiers: 12 months hot or searchable and 18 months cold, with a documented and regularly repeated restore test.
6. Add passive DNS and encrypted traffic metadata for EL2.
7. Plan, then implement, SOAR and UEBA across human and non-human accounts for EL3. See the SOAR and Security Automation Guide.
8. Extend to containers and integrate container security tools with the SIEM. See the NIST SP 800-190 Container Security Guide.

Decision guidance

• Small organisations: target EL1 across all critical sources before any EL2 item; one well-formed, retained, protected log stream beats ten partial ones.
• Large organisations: use the tiers to sequence budget, and treat the 12 plus 18 months retention as a storage architecture question (hot, warm, cold tiers) rather than a SIEM licence question.
• M-21-31 versus NIST SP 800-92 or CIS Control 8: SP 800-92 explains how to run log management as a process, and CIS Control 8 gives a short list of safeguards; M-21-31 is the more prescriptive of the three on fields, categories and retention periods. Many teams use SP 800-92 for the process, M-21-31 for the numbers and CIS Control 8 for board-level reporting.
• Contractors: map each requirement to a contract clause and evidence item; agencies will ask for proof, not policy.

Common failure patterns

• Retention by default: relying on cloud or SaaS default retention of 30 to 90 days, far below 12 months.
• No identity logs from the IdP: collecting endpoint and network logs but not token issuance, consent grants and credential changes.
• Clock drift: sources in local time or unsynchronised, breaking timelines.
• Shared service accounts: a username field that names an account used by twenty services.
• Logs admins can delete: no integrity checks and no separation between system administrators and log custodians.
• Collected but not searchable: cold storage that has never been restored in a test, so the 18 months exist only on paper.

Detection and measurement

• Source coverage: percentage of Appendix C categories present per environment.
• Field completeness: share of events with timestamp, device ID, session ID, IPs and username populated.
• Forwarding latency: median time from event to SIEM.
• Retention compliance: sources meeting 12 months active and 18 months cold.
• Integrity check failures and logging disruption alerts per month, with time to resolve.
• NHI coverage in UEBA: share of service accounts and workload identities with a behaviour baseline.

Framework mapping

See the CIS Control 8 Audit Log Management Guide.

Practitioner checklist

• Every log source is mapped to an Appendix C category and a criticality level.
• Events carry UTC timestamps from an authoritative source, device and session IDs, IPs and username.
• Forwarding is automated, near real-time and encrypted in transit.
• Logs are integrity-checked and log custodians are separate from system administrators.
• Retention is 12 months active and 18 months cold, with a tested restore.
• Passive DNS, including encrypted DNS, identifies the source host of each query.
• Identity provider logs cover token issuance and credential changes for applications.
• UEBA baselines cover service accounts, workload identities and AI agents, not only people.

Standards and references

• OMB: M-21-31 Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents
• OMB: Memoranda (White House archive)
• NIST: SP 800-92 Guide to Computer Security Log Management
• NIST: SP 800-190 Application Container Security Guide
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: NIST SP 800-92 Log Management Guide · Logging and Monitoring Policy Template · Cloud Logging and Audit Trail Guide · UEBA Guide. This guide summarises OMB Memorandum M-21-31 and is not legal advice.