Free cookie consent management tool by TermsFeed Generator Update cookies preferences

Runtime Integrity, Explained

Runtime Integrity
Measurement
Webinar

Answers to the Questions Security Teams Ask

Your security stack has a blind spot, and MITRE just confirmed it. AI-driven and zero-day attacks have never been seen before, so they blind and bypass security tools that operate by watching for signs of an attack. Your stack detects. It does not verify. That gap is where Invary works.

Invary's Runtime Integrity asks a different question: is this system still in the state it was built to be in? That verification is what exposes AI-driven and zero-day compromise at the system level. Unverified systems produce unverified outcomes, and most security stacks never check the one thing every other control depends on. MITRE defines this as the Runtime Integrity gap, and verifying it continuously is something no other commercial product does today.This page answers the questions we hear most often from security architects, CISOs, and engineers evaluating Runtime Integrity.
‍
What is Runtime Integrity?
‍
‍Runtime Integrity is the continuous verification that a system is still in the state it was built to be in, which exposes compromise without depending on the detection of known threats.
‍
Runtime Integrity independently establishes a known-good baseline of a system, continuously measures the running system against that baseline, and surfaces any deviation. It does not look for signatures or suspicious behavior. It verifies that the executing system matches what it is supposed to be, and reports when it does not. This moves security from assuming trust to continuous validation of trust.

The technology comes from high-assurance U.S. government research, developed originally by the NSA, because the most damaging attacks no longer announce themselves. They hide inside the system the security stack depends on. Runtime Integrity also returns value to existing security data, because if you cannot verify that the system itself is intact, every tool sitting on top of it is reporting from a foundation it never checked.

‍Why do AI-driven and zero-day attacks evade EDR and other detection tools?

‍Because detection depends on prior knowledge, and these attacks are built to have none.

EDR, XDR, and antivirus recognize indicators of compromise: signatures, behaviors, and artifacts they have seen or been trained to suspect. AI-driven attacks generate techniques that do not resemble anything in that training. Zero-day attacks exploit flaws no one has cataloged yet. In both cases the attack reaches the system before any detection tool has a reason to fire.

Worse, attackers now target the security tools first. Researchers have catalogued dozens of EDR killers in active ransomware use: get in, blind or bypass the tool, then run the payload. Detection never fires because it can no longer see.

Runtime Integrity does not depend on recognizing the attack. It recognizes that the system changed. Detection closes the door after it recognizes the key used to open it, while Runtime Integrity watches whether the door moved at all. The novelty of an attack does not matter to a control that asks only whether the system is still intact.

‍What technology is Invary built on, and how does the NSA license work?

‍Invary's Runtime Integrity is powered by technology exclusively licensed from the NSA.The foundational technology is Linux Kernel Integrity Measurement, LKIM, developed by the NSA's Laboratory for Advanced Cybersecurity Research to address sophisticated threats targeting core systems in high-assurance defense and intelligence environments. Invary holds the exclusive intellectual property license to LKIM, maintains an active CRADA and ongoing research partnership with the NSA's Laboratory for Advanced Cybersecurity Research, and expanded the technology beyond Linux to also cover the Windows kernel. The work is grounded in issued patents, USPN 8,326,579 and USPN 7,904,278. Because the foundational Kernel Integrity Measurement technology is licensed exclusively to Invary, Runtime Integrity as a deployable capability originates with Invary.

Invary co-authored the MITRE-led Framework for Continuous Remote Attestation, released for public review, and Invary's Runtime Integrity adheres to it. The framework extends the IETF RATS model (RFC 9334) with a layered evidence model: Layer 1 covers platform and hardware state, Layer 2 covers image and software state, and Layer 3 covers runtime state, including kernel integrity. Invary's work anchors Layer 3, the runtime layer where the most consequential attacks happen and where the industry has historically had the least structure. As Invary CEO Jason Rogers puts it, Runtime Integrity is the security outcome, and continuous remote attestation is the evidence model that lets independent relying parties verify it.

The technology supports compliance with NIST, MITRE, ATO, CMMC, and FedRAMP frameworks, and is the same NSA-licensed technology actively deployed in high-assurance defense and intelligence communities.

‍How is Runtime Integrity different from EDR, XDR, or antivirus?

‍Those tools are event-based and reactive. They watch for indicators of compromise and assume the system underneath them is telling the truth. That assumption is their blind spot.

Runtime Integrity verifies the assumption instead of trusting it. It checks the integrity of the kernel and the layers beneath conventional tools, where there is no signature to match and no behavior to flag, only the question of whether the system is in the state it should be. The practical difference shows up against any threat with no indicator yet: an AI-generated technique, a zero-day exploit, an EDR killer modifying kernel memory. Runtime Integrity surfaces the change, not the signature.

‍Does Invary replace my EDR or other security tools?

‍No. Runtime Integrity is complementary, not a replacement.EDR, XDR, and the rest of your stack rely on the integrity of the system they run on. When that integrity is verified, those tools become more trustworthy, because the conditions they assume are now confirmed rather than hoped for. Invary returns value to the broader security stack by validating the foundation that stack depends on and never checks.

Put plainly: your existing tools tell you what is happening on a system. Runtime Integrity tells you whether you can trust what that system is reporting in the first place.

‍What is the business risk of running on unverified systems?

‍Every security, operational, and compliance decision you make assumes the underlying system is trustworthy. If that assumption is wrong, the decisions built on it are wrong too.Your AI models, applications, and security tools are only as trustworthy as the systems they run on. When the foundation has been tampered with, alerts, logs, and automated enforcement are all reporting from a compromised source, so the business may be acting on a false picture of its own security: missed compromise, longer attacker dwell time, and incident response that treats symptoms instead of cause. Runtime Integrity closes that gap by verifying the foundation continuously, which means earlier discovery of serious compromise and more confidence in the conclusions your stack produces.

In regulated and mission-critical environments the same verification becomes evidence. Compliance artifacts usually prove that a control exists, not that the platform running it was intact. Independent Runtime Integrity verification provides defensible attestation that critical systems remained in their trusted state, which strengthens audits, anti-tamper assurance, and Zero Trust claims that would otherwise rest on assumption.

‍Can Runtime Integrity catch zero-day and previously unknown attacks?

‍Yes. This is the heart of why the category exists.

A tool that searches for indicators of compromise can only find what it already knows to look for. A zero-day attack, by definition, has no known indicator. Runtime Integrity does not depend on recognizing the attack. It depends on recognizing that the system has changed from its verified baseline. A recent example: a kernel exploit that corrupts a page in memory while leaving the on-disk file unchanged defeats file integrity tools that compare disk checksums, because nothing on disk changed. Runtime Integrity catches the in-memory modification regardless, because the running system no longer matches its baseline.

The same mechanism surfaces problems that are not attacks at all. Hardware failures and unauthorized configuration changes also move a system away from its known-good state, and they are reported the same way.

‍Why can't EDR and similar tools see kernel-mode rootkits?

‍Because a kernel-mode rootkit compromises the very interfaces those tools rely on to do their work.

Consider Drovorub, a Linux kernel-mode rootkit disclosed jointly by the NSA and FBI. It hooks the system call table and kernel functions directly. Once it does, it can hide its own processes, files, and network connections from anything that asks the kernel about them. Live response tools, antivirus, EDR, XDR, and logging tools all depend on kernel system calls to operate. By compromising those calls, the rootkit compromises every application that uses them, including the security tools hunting for it.

This is the trap of event-based security against kernel-level threats. The tool asks the operating system what is happening, and the operating system has been instructed to lie. Runtime Integrity does not ask the system about itself. It measures the system from a baseline computed independently and appraises the result off-system, so a compromised host cannot hide the change it caused.

‍Is eBPF secure at runtime?

‍eBPF is verified once, when a program loads, and then trusted indefinitely. That load-time check is not a runtime guarantee, which leaves a gap an attacker operating beneath the verifier can exploit.

eBPF runs application code directly in kernel space and powers much of the modern cloud stack, including Cilium for Kubernetes networking and security and tools like Falco and Tetragon. The in-kernel verifier validates a program for safety at load time, but it does not continuously attest that loaded programs, their maps, or the kernel itself stay in their expected state while they execute. An attacker who reaches the kernel can tamper with a program after it passes the verifier, inject a malicious map, or run a rootkit beneath the verifier boundary, while the tooling above keeps reporting a healthy system. An eBPF rootkit can even hide its own programs from bpftool, because that listing relies on a system call the rootkit can hijack.

Invary verifies the Runtime Integrity of the running kernel and its loaded eBPF programs, and Linux customers commonly add eBPF verification to Kernel Runtime Integrity. The appraisal does more than flag a violation. It reports which program, which helper function it used, what that helper does to the system, and the full context: the program's maps, its on-disk binary and hash, and the process and user that loaded it. That context is what separates a real threat from expected behavior. A legitimate security agent and a rootkit can both load many programs and use the same powerful helper, but only one traces back to a signed binary loaded from the expected path by the expected user. Once you confirm a program belongs, you tell Invary to treat it as part of the system's intended behavior, and future appraisals pass. You decide, with full context, what belongs on your system.

‍How does Invary verify a system without being compromised along with it?

‍By performing analysis and appraisal outside the target environment.

This is a defining property of the technology, not an implementation detail. The known-good baseline is computed away from the target by analyzing the kernel binary and its modules. When a system is measured, a lightweight agent captures the actual shape of the running kernel as an object graph, often several hundred thousand nodes representing the static and dynamic structures in kernel memory. That measurement is then appraised against the baseline by a process that runs off-system, where a compromised host cannot tamper with it.

The result is verification that does not trust the thing it is verifying. A rootkit can lie to tools running on the host it controls. It cannot alter an appraisal performed somewhere it does not control, against a baseline it never saw.

‍What does Invary verify, and where does it run?
‍
‍Invary verifies Runtime Integrity across:
- The Linux kernel
- The Windows kernel
- eBPF programs, validating their code, data, and helper usage at runtime, commonly added to Kernel Runtime Integrity by Linux customers
- Trusted Execution Environments such as AMD SEV-SNP
‍
It deploys across embedded, physical, virtual, and air-gapped environments, available as SaaS or as an air-gapped on-premise deployment.

Measurement is continuous, periodic, or on demand, and has low impact on the running system, because the heavy analysis happens once, off the target, before measurement begins.

‍How does Runtime Integrity fit Zero Trust?

‍Zero Trust removes implicit trust from the network and demands that access be continuously verified. But most Zero Trust architectures still rest on an unstated assumption: that the hardware and operating system underneath are themselves uncompromised.

Runtime Integrity verifies that assumption. It strengthens the core of a Zero Trust architecture by removing the assumption that the hardware and OS are sound, confirming instead that the systems making and enforcing trust decisions are operating as intended.
‍
The short version

‍AI-driven and zero-day attacks succeed because detection needs prior knowledge and these attacks have none. Runtime Integrity does not look for the attack. It verifies that the system is still in the state it was built to be in, measuring against a known-good baseline established and appraised independently of the system being checked.

Powered by technology exclusively licensed from the NSA, it covers the kernel, Windows, and eBPF, the layers your security stack assumes are sound and never checks. It does not replace that stack. It validates the foundation underneath it, which is why it surfaces zero-day, AI-driven, and kernel-level threats no matter the technique.

‍See what Runtime Integrity surfaces in your environment. Connect with an expert.

Articles

Articles
Connect with an Expert
Connect with an Expert

Continuous Remote Attestation for the AI Era: A MITRE Framework

by

Invary
,
Read Article

MITRE and Industry Collaborators Invary and Fr0ntierX Release Draft Framework for Continuous Security Verification in Confidential Computing

by

MITRE
,
Read Press Release

Invary Welcomes Former NIST Cybersecurity Chief Donna Dodson to Board of Directors

No items found.
Press Release

Why the Market Needs a Better Model for Trust in Live Systems

by

Fr0ntierX
,

by

Invary
,
Read Article

Invary and Carahsoft Partner to Enhance Protection Against Zero-Day and AI-Driven Threats for Government Agencies

No items found.
Press Release

Designing Trustworthy Layered Attestations

by

Will Thomas
,

by

Logan Schmalz
,

by

Adam Petz
,

by

Dr. Perry Alexander
,

by

Joshua D. Guttman
,
Read Article

EDR Killers: How Modern Attacks Are Outpacing Traditional Defenses

by

Scott Fuhriman
,
Read Article

A New Foundation: Redefining Security with Runtime Integrity

by

Dr. Jaime Gassmann
,
Read Article

Securing Linux and Windows Kernels against Runtime APTs

by

Jason Rogers
,
Read Article

Integrity: An Overlooked Foundation of Zero Trust

by

Scott Fuhriman
,
Read Article

Vibrint and Invary Join Forces to Advance Kernel-Level Zero Trust Solutions

by

Vibrint
,
Press Release

Improving HPC Incident Response with Runtime Integrity in Elasticsearch

by

Dr. Wesley Peck
,
WATCH NOW

Rootkit or EDR

by

Dr. Wesley Peck
,

by

Jason Rogers
,
READ ARTICLE

Why Invary: A Cybersecurity Veteran's Perspective

by

Scott Fuhriman
,
READ ARTICLE

Runtime Integrity Measurement Overview

by

Dr. Wesley Peck
,
READ ARTICLE

How NSA Technology Powers Invary

by

Jason Rogers
,
READ ARTICLE

Invary’s Mission to Ensure the Confidentiality and Security of Systems at Runtime Accelerates with Seed Funding

by

Invary
,
Press Release

Orchestrating Layered Attestations

by

John Ramsdell
,

by

Paul Rowe
,

by

Dr. Perry Alexander
,

by

Sarah Helble
,

by

Peter Loscocco
,
READ ARTICLE

Invary: Breaking the Cycle

by

Jason Rogers
,
READ ARTICLE

Formally Verified Bundling and Appraisal of Evidence for Layered Attestations

by

Dr. Perry Alexander
,

by

Dr. Adam Petz
,
READ ARTICLE

eBPF Rootkit or EDR

by

Steve Perry
,
READ ARTICLE

Flexible Mechanisms for Remote Attestation

by

Sarah Helble
,

by

lan Kretz
,

by

Peter Loscocco
,

by

John Ramsdell
,

by

Paul Rowe
,
READ ARTICLE

Detecting System Compromise

by

Peter Loscocco
,
READ ARTICLE

Design and Formal Verification of a Copland Based Attestation Protocol

by

Dr. Adam Petz
,

by

Grant Jurgensen
,

by

Dr. Perry Alexander
,
READ ARTICLE

An Infrastructure for Faithful Execution of Remote Attestation Protocols

by

Dr. Adam Petz
,

by

Dr. Perry Alexander
,
READ ARTICLE
©2025 Invary. All rights reserved.
Privacy PolicyTerms & ConditionsInvary Linkedin