Integrity is the assurance that information has not been altered in an unauthorised way. Cryptographic controls help detect tampering and preserve the correctness of records, payments, and communications, which is essential where institutions rely on digital evidence and transaction trust.
What Integrity Means in Security
Integrity is the property that lets a recipient trust that data, messages, records, and transactions remain unchanged except through authorised action. It is one of the core trust properties of secure systems, alongside confidentiality and availability.
In practice, integrity answers a simple question: can you rely on what you are seeing or processing? A ledger entry, API response, payment instruction, log record, or software artifact may be available and readable, but still be unsafe if it has been altered without permission.
How Integrity Is Preserved and Checked
Integrity is usually protected with cryptographic and system controls that make tampering detectable or difficult. Common examples include hashes, checksums, message authentication codes, digital signatures, signed builds, append-only logging, and controlled change processes.
The strength of the control depends on the threat. A checksum can detect accidental corruption, but a signature or authenticated integrity check is needed when an active attacker may try to alter the content and then hide the change.
Where Integrity Matters Most
Integrity is especially important where correctness has financial, legal, operational, or safety impact. That includes payment flows, audit logs, software updates, configuration baselines, identity records, clinical data, and any communication where the recipient must know the message was not modified in transit.
It also matters in machine-to-machine environments, where automated systems may act on data immediately. If the data is altered, the downstream action can be wrong even when every system component appears to be functioning normally.
Integrity Failures and Their Consequences
When integrity fails, the damage is often more serious than simple data loss because the system may continue operating on false information. That can lead to fraudulent transactions, corrupted decisions, unsafe automation, misleading audit trails, or software artefacts that no longer match the trusted source.
Integrity problems are difficult because they can be subtle. A single unauthorized change to a record, payload, or configuration can cascade into broader trust failure, especially when multiple systems reuse the altered data as if it were authoritative.
For software and supply-chain integrity, SLSA provides a practical framework for verifying provenance and reducing the chance that build outputs have been tampered with before release. For broader ecosystem guidance on open source security and supply-chain hardening, OpenSSF is a useful reference point.
Risk and Threat Considerations
Integrity failures create a direct trust problem because systems may continue to accept altered data as if it were valid. Attackers often target integrity when they want to change the meaning of a record, redirect a transaction, poison logs, or quietly modify software and configuration without immediately breaking availability.
Failure mechanism: Tampering succeeds when the system lacks strong authenticity checks, change controls, or verification at the point where the data is consumed, so the altered content looks legitimate enough to be used downstream.
Impact: The result can be fraud, corrupted evidence, unsafe decisions, failed audits, broken software provenance, or incorrect automated actions that are hard to unwind once the bad data has propagated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain provenance and integrity | SLSA directly addresses build provenance and artifact integrity for software outputs. |
| Recommendation — Adopt SLSA levels to verify artifact provenance and reduce tampering risk in the build pipeline. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Integrity depends on trustworthy logs that resist unauthorized alteration. |
| Recommendation — Protect log integrity and centralise log retention to preserve tamper-evident evidence. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | SI-7 directly governs detection of unauthorized changes to information and code. |
| SC-16 — Transmission Integrity | SC-16 addresses preserving integrity of information in transit between systems. | |
| Recommendation — Implement SI-7 to detect unauthorized changes to data, firmware, and software artifacts. Use SC-16 to protect message and session integrity across network communications. | ||
| OWASP ASVS | V14 — Data Protection | ASVS V14 covers protecting data integrity and preventing unauthorized modification. |
| Recommendation — Verify V14 controls that detect or prevent unauthorized alteration of protected data. | ||
Practitioner Guidance
Why practitioners should care: Integrity is not only about preventing corruption, it is about preserving decision quality. If downstream systems, auditors, or operators cannot tell whether content was changed, every dependent control becomes weaker.
Common misunderstanding: Many teams assume that encryption alone protects integrity. Confidentiality and integrity are different properties, and a protected channel or stored file still needs explicit tamper detection or authenticated verification.
Practitioner takeaway: Treat integrity as a verification problem at every trust boundary, especially where data is consumed automatically or later used as evidence.
Related resources from NHI Mgmt Group
- Why do file integrity tools miss attacks like Copy Fail?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- What is the difference between provenance and integrity in container security?
- What breaks when mobile banking apps treat device integrity as a binary control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
