CISA's Logging Reference Architecture for OMB M-26-14: What federal agencies should do next

We took a look at the 80-page LRA document, and eight important shifts in logging guidance stand out, as compared to previous guidance under OMB M-21-31.

1. Searchable versus retrievable is now the central storage decision (LRA Section 4.5). The distinction is actually three-way: actively searchable operational data in low-latency tiers, retrievable retained data that may move to lower-cost storage earlier, and designated evidentiary datasets that need immutability and stricter audit. The LRA calls this "one of the most important storage decisions," and insists agencies tie tier placement "directly to outcomes and not to vendor defaults." And the six-month actively searchable baseline binds at every maturity level: Appendix B's requirement stands on its own, even though the memo's maturity model does not demand six searchable months until its top level.

2. Readiness is measured, not asserted. Where the memo's Appendix C measures maturity (five elements, five levels, overall score set by the lowest-scoring element), Section 3.5 of the LRA asks a different question: Does the capability work? Its 10 readiness measures (cost, coverage, timeliness, fidelity, integrity, searchability and retrievability, data quality, operational usability, forensic readiness, and validation maturity) are outcomes you instrument for, not inventory you can read off an architecture diagram, because a mature capability "is not defined by the number of connectors, collectors, or products deployed." The cadence changes, too; the measures are reported at operational and executive levels as a continuous improvement loop, "not something it declares once." 

3. A policy enforcement point is a named architecture component. Minimization, redaction, tagging, routing, access control, and sharing decisions belong in one controlled place, positioned after data is classified, normalized, and enriched but before it crosses agency boundaries. The LRA's reasoning: The same dataset now serves several purposes at once (analytics, longer retention, restricted access, reduced-form sharing), and embedding policy logic separately into every source path or downstream tool makes consistency and change management progressively harder.
4. Producing logs for external authorities is an explicit obligation. The Agency Logging Plan must describe how the agency supports lawful requests from CISA, the FBI, the Office of Inspector General, courts, or legal counsel: locating and scoping the relevant datasets, preserving integrity, meeting required timeframes, and documenting every transformation, reduction, or redaction applied before data leaves the agency. The same section warns against dependence on proprietary structures that make security data hard to export or reinterpret.
5. AI appears on both sides of the ledger. Agencies must log their AI systems: prompts, model outputs, agent decisions and tool interactions, and model lineage, with special care for ephemeral infrastructure where runtime details and non-human identities vanish unless captured early. Section 10 encourages AI for logging operations themselves (anomaly detection, correlation, triage, summarization) while insisting it remain an enabling method rather than a substitute for required telemetry, with model-generated outputs kept distinguishable from event records.
6. Telemetry is organized into nine categories with minimum usable fidelity. The categories run from identity and authentication through network, endpoint, privileged activity, and cloud and SaaS administration, out to IoT and OT devices without native logging, and each is defined by the fidelity that makes it operationally useful, not by the product that emits it. Six common fields every record should carry are the floor for cross-source correlation.
7. Heterogeneity is assumed. Five named architecture patterns, presented neutrally with none mandated, replace any pretense that one monolithic tool is the answer, and the section is direct about the failure mode: "Centralization alone does not guarantee effectiveness; poorly designed central chokepoints can degrade visibility." The guidance includes a list of sub-optimal strategies to avoid and requires the architecture to keep operating, and stay observable, through partial failure.
8. Validation is an expected capability, not an aspiration. The pipeline must detect its own failures (coverage gaps, delivery delays, latency deviations, parser and schema drift) even when the infrastructure looks healthy, using synthetic tests, replay validation, controlled rollout and rollback, and automated threat emulation: "A logging capability that lacks validation of operational functions cannot be considered reliable."

This guidance has roots in previous policies and frameworks. The LRA is grounded in NIST SP 800-61 Rev. 3 and the Cybersecurity Framework 2.0 Community Profile for incident response, and it is explicit about Zero Trust: "The LRA also aligns to zero trust (ZT) principles, consistent with M-22-09, CISA's Zero Trust Maturity Model (ZTMM) Version 2.0, and other federal ZT strategies and is telling you what that plan already implies about telemetry.

Read that way, the eight shifts stop being a compliance checklist and become a set of architecture questions. Five threads run through nearly all of them: telemetry you can use; data you can search; architectures that assume heterogeneity; visibility that reaches identity, cloud, and OT; and a plan that works as a roadmap.

That grounding changes how the document should be read. The LRA is not inventing new obligations so much as spelling out what existing incident-response and Zero Trust (ZT) commitments require from logging. If your agency has a ZT implementation plan, the LRA and OT, and a plan that works as a roadmap, those threads set the agenda for the next 90 days, and they are also where the distance between what the LRA asks for and what runs in production today is shortest.

The agency logging plan due November 18 is the roadmap. Appendix B of the LRA defines seven content areas, from scope and governance through gaps and improvement roadmap, and Appendix C provides the design-decision checklist reviewers will use. The LRA even narrates the journey it expects to receive: from fragmented logging, to an emerging enterprise capability, to logging as an enterprise security function.

Nobody should be writing that plan from a blank page. We at Elastic are committed to partnering with agencies to build efficient and compliant logging strategies. Below are five areas we recommend focusing on when building out your logging plan.

The LRA's quiet headline is that volume is not the goal. Its nine telemetry categories each come with minimum usable fidelity expectations, and Appendix D names the failure mode every SOC recognizes: sources that are technically onboarded but operationally useless. Six common fields (timestamp, event type, identity context, affected resource, outcome, provenance) are the floor for every record.

For this reason, having a schema-first architecture can pay off. Elastic Common Schema (ECS) has been a recognized standard for normalizing exactly these fields for years, and the LRA takes note; it specifically names ECS among "validated, open source cybersecurity schemas" that support searchability (Section 4.5, footnote 9, alongside OCSF and STIX/TAXII).

Normalization you can measure beats normalization you assume. Elastic's Data Set Quality view surfaces degraded documents natively, Elasticsearch's failure store captures every document that fails ingest processing along with which processor failed, and the Elastic M-26-14 Logging Readiness Pack scores field fidelity per LRA telemetry category against the six common fields. When a reviewer asks whether a source is useful, there is a dashboard to point at rather than an opinion to defend.

Section 4.5 of the LRA treats searchable versus retrievable as the storage decision that shapes the rest of the architecture, and Section 5.3 is equally blunt about timing. The memo's six-month actively searchable window is now a baseline obligation, and it applies whether an agency scores at the lowest maturity level or the highest.

For most architectures this is the hard requirement, because keeping six months hot is expensive and keeping it in a cold archive fails the "actively searchable" test. Elastic handles this with searchable snapshots on the frozen tier, which keep data queryable directly from object storage; no restore step or rehydration project required. On day one, an Elastic hot/frozen deployment holds twelve months searchable against the six-month requirement, at object-storage economics.

Frozen queries are naturally slower than hot ones, and Section 3.5 asks agencies to define latency thresholds and measure against them. That means a twelve-month searchability claim needs numbers behind it. A monthly retrieval drill that runs twelve-month queries, restores from snapshot, verifies integrity, and writes the evidence to a validation ledger turns "we believe it is searchable" into "here are last month's validation measurements."

The LRA describes five architecture patterns, from Repository First to Segregated-Access Overlay, and explicitly cautions against a pattern many agencies inherited: routing everything through a premium SIEM first, where per-gigabyte cost quietly becomes the ceiling on visibility. The LRA points readers to ASD's Implementing SIEM and SOAR platforms practitioner guidance as a companion reference for structuring them.

The five patterns map cleanly onto Elastic deployments: Repository First is the day-one hot/frozen platform we recommend; Dual Replication maps to cross-cluster replication or dual agent outputs; Selective Feeds maps to reroute processors and selective forwarding; Segregated-Access Overlay maps to cross-cluster search with spaces and document- and field-level security. The pattern vocabulary is CISA's, and your plan can leverage it directly with Elastic.

Whichever pattern an agency lands on, the LRA attaches two more expectations onto it. The first is durable transport: Section 4.3 treats buffering, checkpointing, replay, back pressure, and queue health as first-class properties, which Logstash persistent queues and dead letter queues provide, with queue health visible in Stack Monitoring. The second is policy enforcement in one controlled place (Section 4.6). Elasticsearch handles this with a final ingest pipeline, a processing step the cluster itself runs last on every document before it is indexed, regardless of which agent, forwarder, or path delivered it. Redaction, tagging, and routing rules applied there run once and uniformly, with no per-source copies to drift out of sync.

The LRA's category list starts with identity and authentication, and its Zero Trust guidance is concrete: Where ZT controls exist, logging should preserve the decision context, including MFA results, device posture, policy evaluation outcomes, privilege elevation, and segmentation decisions (Section 6.2). East-west traffic gets equal billing with north-south. The same goes for cloud: Cloud and SaaS administrative activity should be treated as "core enterprise telemetry rather than as a specialized add-on," since control-plane actions are so often pivotal to modern intrusions. And Appendix D calls out a failure mode most tooling ignores: service accounts and non-person identities that are poorly represented in identity telemetry.

Elastic covers that breadth in one schema: Identity decision context from providers like Okta and Entra ID; device posture from endpoint management; control-plane audit trails from AWS CloudTrail, Azure activity logs, Google Cloud audit logs, and Microsoft 365; and network flow with NAT and DNS context. For OT and IoT environments, where agents often cannot go, passive network-based device discovery gives visibility without touching fragile systems. Entity Store ties it together across hosts, users, and services, so a service account is a first-class entity, not a blind spot.

Section 5.5 treats AI like any other software system and therefore expects agencies to log user prompts, system prompts, model outputs, agent decisions and tool calls, and model versions, with enough context and fidelity to distinguish expected behavior from a guardrail bypass.

Elastic approaches logging your AI from both directions:

• We log our own AI. Elastic Agent Builder conversations are persisted, and every conversation round is recorded as OpenTelemetry traces: model calls, tool calls with arguments and results, and token usage, with administrator-controlled privacy settings governing prompt and response capture. Those traces are ordinary data streams, which means the same retention, integrity, and access controls that protect any other log protect the audit trail of the AI itself.

• We help you log yours. Elastic's AI observability capabilities now include OpenTelemetry-native large language model (LLM) instrumentation through the Elastic Distributions of OpenTelemetry (currently in tech preview) that captures generative AI (GenAI) API calls as spans, metrics, and logs for applications built on providers such as OpenAI, AWS Bedrock, and Google Vertex AI. The platform logging your infrastructure can log your AI systems too.

To AI your logs, Section 10 turns it around and encourages the use of AI for scaling and improving logging operations. Machine learning anomaly detection, Elastic AI Agent, and Attack Discovery already do that work, applying AI to triage, drift detection, and investigation from inside the logging platform rather than bolting it on.

The pattern across all five considerations listed above is the same: The LRA keeps asking agencies to prove things (that fields are populated, that data is searchable, that pipelines work, that retrieval meets timeframes). An architecture that generates its own evidence is the difference between a plan that reads well and a plan that survives review.

Each agency's primary job between now and November 18 is the planning that shapes the order of work: Review what you already run against the Appendix C checklist; begin the plan with the retention, access, and protection sections where the storage decision does the most architectural work; and set the architecture up to generate its own evidence as it operates.

Elastic has supported federal logging modernization since M-21-31, and the foundations the LRA asks for are in the platform out of the box: searchable snapshots for long-window searchability, ECS for common-field normalization, Data Set Quality and the failure store for measurable fidelity, final pipelines for policy enforcement, and built-in machine learning and AI that operationalizes your data. The M-26-14 Logging Readiness package delivers those foundational capabilities shaped to ease your agency's transition.

We’ve spent some time pulling together materials to help you design a logging strategy that can support your agency’s mission and requirements.

Elastic’s M-26-14 Logging Readiness Resources include: 

• An Agency Logging Plan template built on the seven content areas of the LRA, prefilled with the Elastic implementation answer for each

• Relevant dashboards or reports that substantiates these areas

• A crosswalk from the LRA's nine telemetry categories to M-26-14's Appendix B activities; maturity dashboards score progress in the memo's five-level vocabulary and the LRA's three-stage narrative side by side

CISA is expanding and enhancing its SIEMaaS offering for FCEB agencies with explicit alignment to M-26-14, and CDM program manager Matt House confirmed the service is being designed to be "fully compliant out of the box," reducing complexity for agencies.

The LRA gives agencies a shared vocabulary for the decisions that make logging work. The agencies that treat their progress through the M-26-14 maturity levels as an architecture review rather than a paperwork exercise will come out of it with both an approvable plan and a better security program. We can help your agency come up with a plan; please reach out at elastic.co/contact/public-sector.