Missing support for integrity checks means a format, protocol, or component cannot verify whether data has been changed. Without checks, attackers can modify files, messages, or configuration unnoticed. Defenders should require mechanisms that detect tampering, such as authenticated hashes or signatures, and avoid relying on data that cannot be integrity-checked.
What actually causes support for integrity checks to be missing?
Missing support usually comes from design choices rather than a single defect. The format, protocol, or component may never have been built to carry a checksum, signature, or verification field. In other cases, integrity was treated as optional, compatibility with older systems won, or the implementation can move data but cannot prove it was unchanged.
That distinction matters because some systems are inherently “transport only” while others are expected to preserve trust properties end to end. If integrity checks are absent by design, you should treat the data path as unable to detect tampering, not merely under-configured.
Where integrity-check support is typically lost
Support is often missing at boundaries: a legacy file format, a message bus, an API response, or a configuration mechanism that was created before integrity was a requirement. The gap can also appear when a product accepts data from a weaker upstream source and never re-attaches verification, so trust silently degrades as data crosses systems.
Another common cause is inconsistent security engineering. One component may sign data, but a downstream parser, cache, or sync tool strips the metadata or never validates it. If you are evaluating software supply chain integrity, compare the implementation against SLSA and verify whether the build or artifact path preserves provenance, not just availability.
In application and platform settings, the problem often shows up as missing protocol enforcement rather than missing crypto primitives. A system may support hashing or signing somewhere in the stack, but the exact object you care about, file content, message body, or config blob, is never bound to that check in a way the receiver can trust.
What to do when a system cannot verify integrity
First, confirm whether the limitation is structural or merely an implementation gap. If the format or protocol has no field for verification data, the safe response is usually to choose a different format or add a wrapper that carries authenticated integrity data. If the component already supports checks but they are disabled or ignored, treat that as a control failure rather than a compatibility issue.
When the path handles code, artifacts, or released packages, verify the surrounding controls against OpenSSF guidance and the software supply chain model you actually use. For build and release integrity, use an authenticated hash, signature, or equivalent verification step that the consumer enforces before trust is granted.
For systems that move sensitive data or configuration between services, prefer formats and interfaces that make tamper detection explicit. If the receiver cannot verify integrity, assume the data may be altered in transit, in storage, or by a compromised intermediate system. In practice, that means refusing to rely on unauthenticated inputs for security decisions, privileged configuration, or automation triggers.
Risk and Threat Considerations
Missing integrity support creates a direct tampering risk because defenders lose the ability to distinguish original data from modified data. That is especially dangerous for files, messages, and configuration, where silent alteration can change behavior without raising an error.
Failure mechanism: An attacker or compromised intermediary alters content after creation, then relies on the fact that the consumer has no authenticated check to detect the change.
Impact: The result can be unauthorized behavior, poisoned configuration, manipulated updates, or false trust in data that should have been rejected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Integrity gaps often expose secrets or config to silent tampering. |
| Recommendation — Require authenticated integrity checks for secret-bearing files and configs. | ||
| SLSA | Supply-chain integrity | The subject concerns whether artifacts can be trusted after creation. |
| Recommendation — Enforce provenance and verification for artifacts before release or deployment. | ||
| OWASP ASVS | V11 — Cryptography | Authenticated hashes and signatures are the mechanism for integrity verification. |
| Recommendation — Use authenticated hashing or signatures wherever the application must trust data integrity. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | This control directly addresses detecting unauthorized changes to information. |
| SC-16 — Transmission of Security and Privacy Attributes | Integrity metadata must survive transit if receivers are to validate trust. | |
| Recommendation — Implement integrity verification for files, messages, and software before use. Preserve and validate integrity-related attributes across system boundaries. | ||
Practitioner Guidance
What to verify: Check whether the specific object you rely on, not just the surrounding channel, is bound to an authenticated integrity mechanism. A transport may be encrypted and still leave files, payloads, or configs unverifiable once they are stored or forwarded.
Decision rule: If the consumer must trust the content for security-sensitive logic, treat “cannot be integrity-checked” as a design blocker. Use a different format, add an authenticated wrapper, or move the trust decision to a component that can actually validate the object.
Practitioner takeaway: Integrity failures are often hidden in compatibility decisions, so the right question is not whether data can move, but whether the receiving system can prove it has not been changed before acting on it.