Federal teams running RLC Pro Hardened detect kernel-level exploitation while a patch is still in testing. BOD 26-04's three-day clock starts when a vulnerability enters the Known Exploited Vulnerabilities (KEV) catalog, and for the highest-risk flaws the exploit often arrives before the patch. Runtime kernel monitoring is what tells an agency whether that window stayed clean.
For the highest-risk vulnerabilities, exploitation often arrives before the patch, and the BOD 26-04 clock is already running.
The directive assumes a capability most coverage skips past: the ability to see exploitation at the kernel during the interval when a flaw is public and no fix has shipped. That interval is the detection gap, and it is where the hardest part of the three-day standard lives.
The clock starts at disclosure, not at a production patch
BOD 26-04 scores each vulnerability against four criteria: public exposure, presence in the KEV catalog, exploit automation, and technical impact. A flaw that meets all four carries a three-calendar-day remediation deadline. The clock is independent of when a vendor ships a fix.
Under BOD 26-04, the remediation clock for the highest-risk vulnerabilities starts when CISA adds the flaw to the KEV catalog or an agency identifies it on an asset, whichever comes first. Patch availability does not start it.
For a KEV-listed, actively exploited vulnerability, the tested patch can trail the catalog entry by days or weeks. The three days run through that interval. An agency that can only act once a patch exists has already spent part of its window waiting.
Kernel-space exploits leave no trace for user-space tools
The highest-risk tier of BOD 26-04 covers flaws that hand an attacker total control of the machine. Those exploits operate in kernel space. Endpoint detection and response (EDR) watches processes and files in user space, so a kernel exploit that escalates privilege or loads a rootkit runs beneath where EDR looks.
That is the practical shape of the detection gap. A vulnerability is public, the patch is still in testing, and the exploit that matters most is invisible to the tooling most agencies already run. Answering "were we exploited during the window" takes visibility inside the kernel at runtime.
LKRG watches kernel integrity continuously and logs exploitation as it happens
RLC Pro Hardened ships Linux Kernel Runtime Guard (LKRG) 1.0. LKRG validates the integrity of the running kernel on a continuous basis and detects the signatures of exploitation as they occur: unauthorized changes to process credentials, tampering with kernel structures, and the control-flow patterns that privilege-escalation and rootkit techniques rely on.
When LKRG catches an integrity violation, it records the event with a timestamp and streams it to the agency's security information and event management (SIEM) platform. Independent testing has measured LKRG's effectiveness directly. In Juho Junnila's 2020 University of Oulu thesis on Linux rootkit detection tools, LKRG detected 8 of 9 kernel rootkits tested, the strongest result among the tools evaluated.
LKRG turns the pre-patch window from a blind spot into a logged, time-stamped record an agency can hand to an auditor.
See it in a live window. Request a demo of LKRG 1.0 running against a simulated exploit before a patch exists.
Detection and patching are layers, not alternatives
LKRG detects exploitation attempts. It does not prevent them, and it does not replace patching. A tested patch still closes the vulnerability, and it remains the action that clears the BOD 26-04 item.
What LKRG adds is coverage across the window a patching program cannot close on its own. Reactive patching answers "is the flaw fixed." Runtime monitoring answers "was the flaw exploited before the fix arrived." The directive's highest tier now asks both questions, and the two capabilities work together rather than competing.
Verify your kernel visibility before a BOD 26-04 event
Three checks tell a team whether it can answer the directive's detection question today. Can you see privilege escalation or rootkit behavior at the kernel, or does your telemetry stop at user space? When an exploit fires, does it produce a logged, time-stamped record, or an educated guess? And is that record already flowing to your SIEM, so the timeline exists before an auditor asks for it?
A team that answers "no" to any of these carries the detection gap into its next KEV-catalog entry. The fix is a base operating system that treats kernel visibility as a default, not an add-on.
RLC Pro Hardened ships LKRG configured for the window
RLC Pro Hardened arrives with LKRG 1.0 enabled, signed into the Secure Boot chain, and supported by CIQ. It is the hardened base of the CIQ stack for federal security and compliance, where Ascender Pro adds automated remediation on top of the detection layer. Agencies get kernel-level detection running from first boot, on a distribution already aligned to their compliance requirements.
BOD 26-04 assumes federal teams can see what happens at the kernel while a patch is still in testing. RLC Pro Hardened gives them that visibility as a standard part of the platform.
