The Logging Reference Architecture Landed. Now the Clock Starts.

Three months ago I wrote that M-26-14 asked the right strategic questions, and that everything downstream depended on whether CISA’s Logging Reference Architecture arrived with real substance or as a restatement of the memo with a diagram on top. It arrived. In August, CISA published the LRA — TLP:CLEAR, eighty pages, six appendices, and more architectural specificity than the federal logging community has seen in a policy-adjacent document before. It is better than I expected. It also documents a compliance gap most agencies have not noticed yet, in a paragraph almost everyone will skim past.

CISA Delivered More Than a Restatement

The LRA is explicit about what it refuses to be: “not a tool implementation manual, product selection guide, or vendor-specific schema.” What it gives instead is a set of named architecture decisions — telemetry, collection, transport, normalization, searchable versus retrievable handling, policy enforcement, and validation plus five common architecture patterns (Repository First, Dual Replication, Selective Feeds, SIEM First, and a Segregated-Access Overlay that sits on top of the other four) that agencies can honestly map themselves against. Section 6 defines nine baseline telemetry categories with minimum event fidelity for each. Appendices C and E are design and validation checklists that read like they were written by someone who has run a SOC during a bad week, not by someone assembling a compliance artifact.

The most immediately useful thing in the document is Appendix A. Table A-1 crosswalks each M-26-14 requirement to the LRA sections that implement it; Table A-2 maps the rescinded M-21-31 Appendix C log categories into LRA Appendix D and Section 6. If your agency spent 2022 through 2025 building to EL1/EL2/EL3, that second table is how you show the investment carried forward instead of writing it off. The IoT/OT gap I complained about in May is genuinely addressed in §6.2.9 — gateway aggregation, network-based monitoring, scheduled polling, and store-and-forward for devices with no native logging, with minimum fidelity still applying no matter how the data was collected. The governing sentence sits just above it in §6.2.8, and I would put it on a wall: “the operational standard should not be lower just because collection is harder.”

Two Standards, Two Clocks, and a Gap Between Them

Now go to §5.3, page 19. Everyone, including me, quoted the headline retention change: six months actively searchable, twelve months retrievable. That is M-26-14 Appendix B, Requirement 1: the mandatory baseline, and it binds now.

Then open Figure 3, the M-26-14 Appendix C maturity model reproduced in LRA §11. Under Data Retention, Level 1 is retrievable for six months. Level 2, retrievable for twelve. Level 3 — Advanced — is searchable for three months and retrievable for twelve. Level 4, Optimal, is searchable for six months and retrievable for twelve.

Credit where it’s due: CISA saw this and wrote it down plainly. Appendix B defines mandatory baseline expectations; Appendix C defines maturity benchmarks. Agencies are required to reach Advanced within 320 days, and doing so satisfies maturity reporting but, the LRA says, “agencies must still ensure their architectures meet the six-month searchable baseline in Appendix B to comply with M-26-14.”

Read that carefully, because it may be the most consequential sentence in the document. An agency can hit its mandated maturity level, report Advanced, and still be out of compliance with the memo on searchable retention. Two standards, two clocks, one budget. If you are writing an Agency Logging Plan, report your maturity level and your baseline conformance as two separate answers. They are two separate questions, and conflating them is how a program ends up scoring well and going dark during an incident.

Coverage Is Not Capability

The sharpest paragraph in the LRA is §6.4, which names the failure modes familiar to anyone who has worked an incident: source presence without usable detail, retention without searchability, and normalized data without recoverable source meaning. A connector can be green and operationally worthless. Treat baseline coverage as a question of usable capability, not nominal connector presence; that is the single idea I would want a CISO to take from the document. Its companion, in §5.3, is just as blunt: centralization is not the same as usefulness.

Section 8 is worth reading twice. It treats the logging infrastructure itself as a high-value target and says plainly that “treating only the SIEM or main analytics tier as the critical asset is too narrow” — collectors, brokers, parsers, storage tiers, and administrative interfaces are all in scope. Section 8.3 then names sub-optimal strategies outright: point-to-point integrations, polling as the default where timeliness matters, a single fragile pipeline, normalization that discards investigative context, unmanaged exceptions that bypass policy enforcement, and vendor-dependent handling that leaves essential telemetry outside agency control. That last one is a lock-in warning in a federal reference document, and agencies should read it as license to ask harder questions at renewal.

On AI, §10 is more disciplined than most vendor marketing will admit. Anomaly detection, weak-signal discovery, timeline reconstruction, parser-failure and schema-drift detection. But the Agency Logging Plan has to distinguish event records from model-generated scores, summaries, and recommendations; AI output must stay tied to underlying event records and analyst-reviewable rationale; it must never alter source evidence or replace chain-of-custody controls; and material containment, disclosure, legal, or privacy-impacting actions require human review. That boundary table is the paragraph that gets skipped in the demo.

What the Next 90 Days Should Actually Look Like

M-26-14 gives agencies 90 days from LRA publication to get an Agency Logging Plan to OMB and CISA, with the template hosted on CyberScope. That puts submissions this fall. Five things worth doing before the writing starts:

  1. Score maturity and baseline conformance separately. Per the above. If they disagree, say so in the plan rather than letting a reviewer find it.
  2. Run the Appendix E validation checklist before you draft, not after. Synthetic event injection, timestamp validation, parser health, replay, and gap detection will tell you how much of your claimed coverage is real.
  3. Fix time first. Section 6.3 wants NTP or equivalent synchronization to a traceable, agency-designated time source, and where feasible one traceable to USNO or NIST. Inconsistent timestamps quietly invalidate every correlation downstream of them.
  4. Use the §9.3 five-step method for above-baseline decisions and write the justification down. “Richer telemetry on HVAs” without a mapped threat scenario and a specific investigative question is an unfunded preference, not an architecture decision.
  5. Name your gaps. Appendix B expects a gaps and improvement roadmap with accountable owners and target milestones. A plan claiming complete coverage will not survive its first real incident, and OMB and CISA will be reading these side by side across the enterprise.

Final Thoughts

In May my worry was that “risk-based” would be read across the FCEB as permission to log less. The LRA closes that door about as firmly as a non-binding reference document can — §6.2.1 says the identity analytics agencies built under M-21-31 “should be preserved rather than scaled back,” and the above-baseline method in §9 is a process for spending more deliberately, not for spending less. The remaining risk is not the guidance. It is a 90-day plan deadline, a 320-day maturity deadline, and a baseline requirement that binds independently of both. The agencies that come out of this well will treat the Agency Logging Plan as an engineering decision record they revisit, not a document they submit this fall and reopen in a year.

If you’d like to learn more about how S2i2 can help, contact us at info@s2i2.com or call us at 1-844-946-7242. Follow us on LinkedIn for more updates from the S2i2 team.

Related

More from S2i2