Integrity Checking

What Integrity Checking Protects

Integrity checking is only useful when the thing being checked matters operationally. In practice, that means validating that files, binaries, configurations, messages, and identity-related artefacts still match the expected state, so defenders can distinguish a trusted object from one that has been altered.

Its value is not limited to software supply chains. Integrity controls also help protect endpoint configuration baselines, cloud settings, authentication material, and logs, where even a small change can change system behaviour, weaken trust, or conceal abuse.

How Integrity Checking Works

The basic pattern is comparison. A system calculates or verifies a hash, signature, checksum, or attestation result and compares it with a trusted reference. If the values diverge, the object is no longer assumed to be authentic or unchanged.

Different mechanisms serve different purposes. Hashes and checksums are good for detecting accidental or unexpected drift, while digital signatures and attestations add stronger assurance about origin, state, or platform trust. The control is strongest when the reference value is protected separately from the object being checked.

Where Integrity Checking Matters Most

Integrity checking is central in software delivery, endpoint defence, cloud configuration management, and identity and access environments. It helps confirm that code was not swapped, a configuration was not silently modified, or a sensitive message or token was not tampered with in transit or at rest.

It is especially important where systems make security decisions based on what they read. A compromised policy file, altered registry entry, or modified control script can change permissions, disable protections, or create a false sense of compliance without immediately breaking availability.

What Good Integrity Checking Tells You

A successful check does more than say “the file exists.” It says the object still matches the expected state that defenders are willing to trust. That makes integrity checking a trust signal, not just a validation step.

Strong implementations also define what counts as a trusted baseline, who can update that baseline, and when revalidation happens. Without those governance decisions, integrity data can be stale, spoofed, or too weak to support meaningful security decisions.

Risk and Threat Considerations

Integrity failures can turn trusted assets into hidden attack paths. If an attacker can modify code, configuration, logs, or identity material without detection, they may persist longer, evade monitoring, or redirect systems to unsafe behaviour.

Failure mechanism: Integrity checking fails when the trusted reference is weak, when verification is skipped, or when the attacker can alter both the object and the baseline used to validate it.

Impact: The organisation may continue operating on corrupted inputs, trust poisoned evidence, or miss compromise of software, configuration, sessions, or authentication-related material.

Practitioner Guidance

Why practitioners should care: Integrity checking only works when it is tied to a trustworthy reference, a clear scope, and a defined response to mismatch. Treat it as part of a control chain, not as a standalone signal.

What to watch for: Repeated mismatches, unexplained baseline updates, unsigned artefacts, or integrity checks that succeed even after suspicious change are indicators that the control is not protecting the right trust boundary.

Practitioner takeaway: Use integrity checking to surface change you did not expect, then pair it with review of provenance, baseline ownership, and the systems that consume the checked object.

Related resources from NHI Mgmt Group

• What breaks when a downloader writes untrusted data before checking integrity?
• What is the difference between code signing and code integrity checking?
• How should election security teams evaluate self-checking integrity features on voting devices?
• How does Driver Load Integrity Checking work?