Integrity Measurement Architecture (IMA) is a Linux kernel feature that measures files and other objects at runtime and records those measurements for attestation or appraisal. It helps detect unauthorised changes to executables, scripts, and configuration. Defenders use it to prove system integrity, while attackers try to replace measured files or evade policy.
What Integrity Measurement Architecture Does
Integrity Measurement Architecture, or IMA, is a Linux kernel control that continuously records measurements of files and related objects as they are accessed. It gives defenders a way to prove what was present and detect when system content has changed unexpectedly.
That makes IMA different from simple file monitoring. It is not just watching for change events, it is creating integrity evidence that can later support attestation, appraisal, or post-incident review.
Why Runtime Measurement Matters
IMA is useful because compromise often shows up as a trusted file being replaced, altered, or loaded after an attacker has already gained some level of access. If executables, scripts, or configuration files are modified in place, the system may keep running while silently drifting away from the approved state.
By measuring objects at runtime, IMA helps close that gap between “the file was supposed to be trusted” and “the file was actually the one that executed or loaded.” In practice, that makes it valuable for proving integrity across boot, login, service start, and other execution paths where tampering would otherwise be hard to see.
How IMA Supports Attestation and Appraisal
IMA measurements become most powerful when they are used as evidence, not just as local telemetry. A verifier can compare the recorded measurements against an expected baseline, or a local policy can appraise whether a file should be allowed to run or be read.
This is why IMA is often discussed alongside broader integrity and supply-chain assurance work. The control does not prove that software is safe by itself, but it can prove whether the system state matches what administrators intended and whether a change deserves trust.
For readers mapping the concept to software integrity practice, the most relevant reference is SLSA, because both approaches are concerned with proving integrity rather than assuming it. Open-source supply-chain work from OpenSSF also sits naturally in this conversation because it focuses on protecting the trust boundary between build provenance and runtime assurance.
Common Failure Modes and Operational Limits
IMA is only as useful as the policy and measurement points you choose. If the wrong objects are excluded, if the baseline is incomplete, or if an attacker can alter files before they are measured, the resulting evidence may miss the compromise. A strong control can still be undermined by weak enrollment, poor policy design, or gaps in object coverage.
Defenders also need to treat IMA data as part of a larger integrity story, not a standalone guarantee. Measuring a file is valuable, but it does not by itself prevent privilege escalation, kernel compromise, or abuse of already-trusted code paths.
Risk and Threat Considerations
IMA addresses a real integrity risk: if an attacker can replace a binary, script, or config file without being detected, the system may continue operating with altered behavior while appearing normal. That makes the control especially valuable on hosts where trust in local files determines execution or authorization decisions.
Failure mechanism: The attacker changes a measured object before execution, abuses a gap in policy coverage, or targets a path that is not being measured, so the integrity record no longer reflects the effective system state.
Impact: The defender may lose confidence in the host's integrity evidence, miss unauthorized code execution, or accept a compromised system as trustworthy during attestation or incident review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | SLSA directly addresses software integrity and provenance, which IMA helps verify at runtime. |
| Recommendation — Require provenance evidence for software and validate runtime integrity against trusted artifact history. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | SI-7 governs detection and response to unauthorized integrity changes on systems and files. |
| AU-2 — Event Logging | IMA measurements create integrity evidence that must be logged and retained for review and attestation. | |
| CM-5 — Access Restrictions for Change | IMA is strengthened when change paths are tightly controlled so trusted files are harder to alter. | |
| Recommendation — Implement SI-7 checks to detect unauthorized changes and trigger integrity response actions. Log integrity events so measurement records can support investigation and attestation. Restrict system changes to approved paths and reduce unauthorized modification opportunities. | ||
Practitioner Guidance
Why practitioners should care: IMA is most effective when it is aligned to the files and execution paths that actually matter to your platform. If it is deployed without a clear baseline and review process, it can produce a lot of data without materially improving trust.
What to watch for: Pay close attention to drift between expected and observed measurements, especially after package changes, image updates, or unexpected service restarts. Those are the moments when a legitimate change and a malicious replacement can look similar until the evidence is reviewed.
Practitioner takeaway: Treat IMA as an integrity evidence layer, then pair it with strong policy design, attestation review, and post-change validation so the measurements remain meaningful.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org