Confidentiality prevents unauthorized parties from reading information, while integrity ensures the information cannot be changed without detection. Both are needed in banking and digital identity workflows. A system can hide data successfully and still fail if an attacker can alter records, so cryptography must protect both secrecy and correctness of the information.
Why confidentiality and integrity are different security properties
Confidentiality and integrity protect different parts of cryptographic assurance. Confidentiality is about who can see the data, while integrity is about whether the data can be trusted as unchanged. A message can remain secret and still be modified, and a record can be altered without the attacker ever learning its contents.
That distinction matters because cryptography is often deployed in layers. Encryption alone addresses secrecy, but it does not prove the data was not rewritten in transit or after storage. integrity controls, such as authenticated encryption or message authentication, add tamper evidence and help the receiver distinguish genuine data from manipulated data.
How each property shows up in real systems
In practice, confidentiality is usually implemented with encryption, key management, and access to the decryption keys. If the key is protected, the content stays unreadable to unauthorised parties. NIST guidance on cryptographic protections treats secrecy as a control objective that depends on both algorithm choice and key handling, not encryption alone.
Integrity is usually enforced with hashes, MACs, digital signatures, and authenticated encryption modes that detect tampering. The core question is not whether the data is hidden, but whether a verifier can tell that it has been altered. SLSA is a useful example of integrity thinking in software supply chains, where the issue is proving that artifacts have not been modified after trusted creation.
These two properties often work together but solve different failure modes. For banking instructions, encryption protects the transaction details from disclosure, while integrity protects the amount, destination, and authorisation context from silent alteration. In digital identity workflows, the same separation matters when protecting assertions, tokens, or signed records that must remain both private and unmodified.
What practitioners should compare when choosing cryptographic controls
Start with the question you are trying to answer. If the main concern is exposure of sensitive information, confidentiality controls are the priority. If the main concern is whether the data can be altered, replayed, or forged, integrity controls become the critical requirement. Many production failures happen when teams assume encryption automatically covers both.
For high-value workflows, you usually want both properties, but not always in the same mechanism. CIS Controls v8 aligns with the operational view that data protection, access management, and logging should complement cryptography so that secrecy and tamper detection are both covered. ISO/IEC 27001:2022 reinforces the same point by separating cryptographic controls from broader access and information protection obligations.
Risk and Threat Considerations
Confidentiality failures expose sensitive information to unauthorised reading, but integrity failures can be worse in transactional systems because an attacker may not need to learn the data to cause damage. If a record can be altered without detection, a system may make confident decisions on false inputs, which is especially dangerous in payments, identity, and control-plane data.
Failure mechanism: Weak or misapplied crypto can provide secrecy while leaving data unauthenticated, allowing replay, substitution, or silent modification of records, messages, or tokens.
Impact: The result can be fraud, incorrect state, unauthorised action, broken auditability, or downstream trust in data that no longer reflects what was originally sent or approved.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and SLSA set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Key management is central to confidentiality and integrity controls. |
| SC-13 — Cryptographic Protection | Cryptographic protection directly covers confidentiality and integrity. | |
| SI-7 — Software, Firmware, and Information Integrity | Integrity controls must detect unauthorized changes to information and artifacts. | |
| Recommendation — Manage keys with approved lifecycles so encryption and signatures remain trustworthy. Apply cryptographic protection appropriate to data sensitivity and tamper risk. Verify integrity checks and alerts before trusting protected information. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Annex A cryptography control directly supports secrecy and integrity protections. |
| A.5.15 — Access control | Access control complements cryptography by limiting who can read protected data. | |
| A.8.15 — Logging | Logging supports detection and investigation when integrity is compromised. | |
| Recommendation — Select cryptographic controls that protect both confidentiality and integrity where needed. Restrict access to decrypted data and key material to the minimum necessary. Retain logs that help detect tampering and confirm data-handling events. | ||
| OWASP ASVS | V11 — Cryptography | ASVS covers cryptographic safeguards used by web and API applications. |
| V14 — Data Protection | Data protection requirements distinguish secrecy from authenticity and integrity. | |
| V16 — Security Logging and Error Handling | Integrity failures are easier to investigate when security events are logged. | |
| Recommendation — Use approved cryptographic patterns that preserve confidentiality and detect tampering. Protect sensitive data with controls that address both disclosure and modification risks. Log validation failures and suspicious message changes for later review. | ||
| SLSA | Supply chain integrity | SLSA is directly relevant because it formalizes integrity verification for build artifacts. |
| Recommendation — Use provenance and verification to ensure artifacts have not been altered after trusted creation. | ||
Practitioner Guidance
What to verify: Check whether the control actually provides confidentiality only, integrity only, or both. If the design relies on encryption without authentication, treat that as an incomplete control for any workflow where tampering would matter.
Decision rule: If an attacker could gain value by changing the data rather than reading it, prioritise integrity protection at least as strongly as secrecy. For message exchange, signed or authenticated encryption is usually a better default than encryption without tamper detection.
Common mistake: Teams often stop at “the data is encrypted” and assume the problem is solved. In practice, the useful test is whether the receiver can both keep the content private and prove it has not been altered.
Practitioner takeaway: Confidentiality protects information from disclosure, but integrity protects it from becoming untrustworthy; good cryptographic design treats those as separate requirements and validates both against the business risk of the data.
Related resources from NHI Mgmt Group
- What is the difference between obfuscating JavaScript and adding self-defending controls?
- What is the difference between device intelligence and account-based fraud controls?
- What is the difference between identity-based file protection and data-centric encryption controls?
- What is the difference between checking algorithm constraints and simply reviewing code for cryptographic use?
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
