Integrity Controls

What integrity controls do

Integrity controls are about proving that something has not changed in an unauthorised or unexpected way. They are used to compare a live system, file, configuration, or cryptographic asset against a trusted baseline, so defenders can spot tampering early and treat deviation as a security signal rather than a routine change.

That makes integrity a verification problem as much as a protection problem. The control is only useful if the baseline is trustworthy, the comparison is repeatable, and the alert path is reliable enough to surface drift before an attacker can use it to persist, hide, or alter security behaviour.

Where integrity controls are used

Integrity controls show up anywhere state must remain stable or provable. Common examples include file integrity monitoring, configuration drift detection, code signing checks, secure boot measurements, and validation of security-relevant cryptographic material such as certificates, keys, or policy files. In each case, the goal is to detect unauthorised modification, not to restore the system automatically by itself.

They are especially important where a small change can have outsized impact. A modified binary, altered startup setting, changed registry entry, or tampered policy object may look harmless in isolation, yet it can create a durable foothold or silently weaken the control stack that other security tools depend on.

How integrity is established and compared

An integrity control usually depends on three linked ideas: a trusted reference state, a method of measuring the current state, and a decision rule for what counts as acceptable drift. That reference might be a hash, signature, manifest, policy snapshot, or recorded configuration state. The comparison must be anchored in trust, otherwise the attacker can simply change both the object and the baseline.

Because of that, integrity is often strongest when it is layered. Platform measurements, signed updates, protected baselines, and restricted change pathways each reduce the chance that tampering can occur unnoticed. Good integrity design also distinguishes expected change from suspicious change, so routine administration does not drown out genuine modification.

Why integrity controls matter for detection and response

Integrity controls are often one of the first ways defenders notice compromise. They can reveal post-exploitation changes that do not trigger traditional malware detections, including altered autoruns, replaced binaries, modified libraries, or changed configuration values that redirect trust or suppress logging.

They also support response work after an incident. If integrity monitoring shows exactly what changed and when, teams can scope the compromise faster, separate attacker activity from approved administration, and decide whether a rebuild, rollback, or broader trust reset is needed. For broader provenance and build integrity concerns, SLSA is a useful reference point, and OpenSSF provides adjacent supply-chain integrity guidance.

Risk and Threat Considerations

Integrity controls fail when the baseline is weak, the comparison is incomplete, or the attacker can tamper with both the protected object and the mechanism that checks it. That creates a blind spot where compromise looks like normal state, especially if the change affects logging, startup behaviour, or trust anchors.

Failure mechanism: An attacker modifies a file, configuration, or signed asset, then weakens or bypasses the integrity check so the drift is never surfaced, or is surfaced too late to matter.

Impact: The organisation may keep operating on compromised trust assumptions, which can extend dwell time, hide persistence, and allow later privilege escalation, data manipulation, or credential abuse.

Practitioner Guidance

Why practitioners should care: Integrity controls are only as strong as the trust placed in the baseline and the coverage of the comparison. A narrow or noisy control can create false confidence, which is dangerous because integrity failures are often used by attackers to blend in with legitimate administration.

What to watch for: Pay close attention to unmanaged exceptions, frequent baseline resets, and integrity tools that cannot clearly separate approved change from unapproved drift. If the comparison surface is too small, critical tampering can sit just outside it.

Practitioner takeaway: Treat integrity as an end-to-end trust chain, not just a hash check, and make sure the baseline, the sensor, and the response path are all protected.

Related resources from NHI Mgmt Group

• How should security teams use file integrity monitoring alongside other controls?
• What breaks when a company has integrity controls but weak data stewardship?
• What breaks when DNS integrity controls are missing?
• What is the difference between DNS failover and DNS integrity controls?