CISA Says Your Logging Is Not Reliable Unless You Can Prove It Still Works

Most logging guidance is a list of sources to collect. CISA's new Logging Reference Architecture is not that, and the difference is the point. It was published on 20 August 2026 to implement OMB memorandum M-26-14, and it is written for the people who have already bought a SIEM and still cannot answer basic questions during an incident.

The line it leads with is the one worth sitting with:

That is a harder standard than it looks. It is not asking whether data arrived. It is asking how you would know it stopped arriving, while every dashboard still looked healthy.

The failure modes it names

Section 6.4 lists what materially degrades operations, and it reads like a description of most estates rather than a theoretical risk register:

• Source presence without usable detail. The feed is onboarded and the records cannot support scoping or reconstruction.
• Retention without searchability. The data exists, in a tier or structure that cannot answer a question in time.
• Normalized data without recoverable source meaning. It powers dashboards and counts, and it cannot support an actual investigation.
• Unreliable or inconsistent timestamps across major telemetry classes.
• Alerting pipelines that cannot be validated against raw or high fidelity context.

The timestamp one deserves attention because it is the quietest. A host whose clock has drifted drops nothing and errors on nothing. Every panel keeps working. What it destroys is the timeline reconstruction that the same document says endpoint telemetry exists for, and it destroys it in a way nobody can see from the data.

What we do about it. Every one of those five is something Caver reports on itself rather than leaving you to discover during an incident. A source that stops arriving raises an alert instead of showing as a quiet week. Collection fidelity is a field on the event, so a degraded collector reads as degraded rather than as an absence of activity. And the raw record is preserved underneath the normalized one, which is the whole point of the third failure mode: you can still reconstruct when the dashboard was not enough.

It names OCSF

In a footnote to section 4.5, CISA lists examples of validated open schemas eligible for federal use: the Open Cybersecurity Schema Framework, Elastic Common Schema, and STIX and TAXII.

This matters more than a footnote suggests. Schema arguments in this industry are usually vendor positioning. A federal architecture document naming OCSF as eligible turns a preference into a procurement fact, and it gives an agency cover to require it.

We were already there. Caver is OCSF underneath, not OCSF as an export option bolted on for a checkbox. The lake is OCSF Parquet, the detection content is written against OCSF classes, and the schema CISA just called eligible is the one our storage format already is. Nobody has to migrate to satisfy this paragraph.

Durable normalization, not query time only

Section 7.1 contains a sentence that quietly rules out a popular architecture:

Schema-on-read is fast to sell and it puts the normalization on the analyst at the worst possible moment. CISA also asks specifically that parent and child execution relationships be normalized, which is the difference between having process events and being able to follow a chain through them.

This is the sentence that separates architectures. Caver normalizes once, on the way in, and stores the result. Parent and child execution relationships are resolved at that point, not reassembled by an analyst at 3am under a schema someone can edit while an investigation is running. Query-time transformation is fast to demo and it puts the hard part on the person with the least time.

Integrity is a property of the path, not the disk

Section 8.2 is the part most teams will underestimate. It asks for hashing on upload, movement and access, signing, immutable handling, auditable transfer paths, and preservation of provenance and transformation history. Then it makes the argument that matters:

Treating integrity as a storage feature, which is where most products put it, leaves every one of those uncovered.

We own the whole path, which is why we can make this claim. Most of this market receives data after somebody else has collected and shipped it, so the half of the path where CISA says integrity is most often lost is the half that product never sees. Our own agent collects it, our own collector forwards it, and the transformation history travels with the record. Chain of custody is a product surface, not a policy document.

The maturity scale is a self assessment

Section 11.1 describes three stages. Stage 1 is characterised by uneven source coverage, weak cloud control plane visibility, limited correlation between identity, endpoint and network data, no explicit distinction between actively searchable and retrievable data, and limited validation of timeliness, completeness or parser health.

Read that as a checklist rather than a description. Most estates fail several lines of it, and the document is polite enough to call that a starting point rather than a failure.

What it rules out, without ever naming a product

Read 6.4 next to 7.1 and 8.2 and a shape emerges. The document names no vendor and no category, and it does not have to, because the constraints it sets are ones a large part of the market cannot satisfy without changing how it charges and where it puts your data.

• Retention without searchability is a failure, not a tier. An architecture that meters ingest and then sells you a cheaper archive you must rehydrate before asking it anything has that failure mode as its business model.
• Query-time normalization is ruled out on its own. 7.1 permits it only where transformations are stable, governed and operationally available, a bar most schema-on-read deployments have never been asked to clear.
• Integrity has to hold across the path. Collection, forwarding, parsing, silent transformation, privileged administrative action. A product that receives data after someone else collected and shipped it cannot answer for the half where the document says integrity is most often lost.
• The maturity stages want evidence. A self assessment nobody can reproduce is an attestation. 6.2.5 and 6.2.8 ask you to demonstrate.

None of that is a product recommendation. It is a set of constraints, and it happens to describe an architecture where the lake is the system of record rather than a discount tier, where normalization is durable rather than deferred, and where collection and integrity ship as the same product as search.

What to actually do with it

1. Test for silence, not just for data. Pick a noisy source, stop it, and time how long until something tells you. If the answer is a person noticing, that is the finding.
2. Check your clocks. Compare event time against receive time per source. A sustained offset is a broken timeline nobody has noticed yet.
3. Write down which datasets must stay searchable and for how long, separately from how long they are retained. If those two numbers are the same number, you are paying for one and using the other.
4. Ask where your normalization lives. If it exists only inside saved searches, it is one query rewrite away from being gone.
5. Name the datasets that need tamper evidence before an incident, not during one.

The architecture is 80 pages and worth reading directly rather than through a vendor summary, including this one. It is published at cisa.gov, and the underlying memorandum is OMB M-26-14.