A.8.24 Technological
Use of cryptography
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (18)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- SC-12fullcovers — A.8.24's mandate to ensure proper and effective use of cryptography according to all relevant requirements directly accounts for the entirety of SC-12's requirement to establish and manage keys when cryptography is used.
- SC-13fullcovers — SC-13's entire requirement (selecting and implementing the exact cryptography required per use case) is completely accounted for inside the broader mandate of A.8.24 to ensure proper and effective use of cryptography per business, security, legal and regulatory needs.
- SC-12mostlyaligns with — Both controls establish requirements for the full lifecycle management of cryptographic keys, including generation, distribution, storage, rotation, revocation, recovery, and destruction.
- SC-13mostlyaligns with — Both controls require organizations to select and apply approved cryptographic algorithms and mechanisms that match the sensitivity of the information being protected.
- SC-28mostlycovers — A.8.24's mandate to select and apply cryptography for confidentiality/integrity directly accounts for the bulk of SC-28's protection-at-rest requirement when cryptography is the chosen mechanism, but leaves a residual where non-cryptographic protections (e.g., OS-level access controls or physical media controls) could satisfy SC-28 without invoking cryptography.
- SC-8mostlycovers — A.8.24's mandate to select and apply cryptography per requirements (including confidentiality/integrity) accounts for the bulk of SC-8's protection objective, but leaves a residual on the specific transmission-focused mechanisms, parameters, and boundary enforcement that SC-8 requires beyond general crypto policy.
- CM-6partialaligns with — Both controls require the organization to define and enforce approved cryptographic standards, algorithms, and configuration settings.
- SC-28partialaligns with — Both controls require cryptographic protection for information at rest on endpoint devices and storage media.
- SC-8partialaligns with — Both controls address the use of cryptography to protect the confidentiality and integrity of information transmitted over networks.
Aligned NIST CSF 2.0 outcomes (18)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.DS-01mostlyaligns with — The control establishes cryptographic mechanisms and key-management processes that directly protect the confidentiality and integrity of data at rest on endpoints and storage media.
- PR.DS-02mostlyaligns with — The control mandates the use of approved cryptographic algorithms and key handling to protect data transmitted over networks to mobile devices and storage media.
- GV.PO-01partialaligns with — The control explicitly calls for a topic-specific policy on cryptography that is derived from organizational context and risk priorities.
- GV.SC-05partialaligns with — The control requires that contracts and SLAs with external cryptographic-service providers address liability, reliability, and response times, thereby embedding cryptographic requirements into supplier agreements.
- ID.RA-09partialaligns with — The control’s emphasis on selecting approved cryptographic solutions and assessing their strength supports the authenticity and integrity evaluation of software and hardware prior to acquisition.
- PR.PS-01partialaligns with — The control requires an organization-wide policy and approved standards for cryptographic algorithms and usage, which are foundational elements of configuration management.
- GV.PO-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.RA-09implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.DS-01implements — A.8.24 operationalizes data-at-rest protection (via mandated cryptography) within PR.DS-01's domain, but the outcome does not name cryptography specifically — access control and physical protection also serve it
- PR.DS-02implements — A.8.24 operationalizes protection of data-in-transit confidentiality and integrity (core parts of the PR.DS-02 outcome) via its mandated cryptographic controls, which sit inside that protection domain even though the CSF outcome does not name cryptography explicitly
- PR.PS-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (12)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V11.1.1mostlycovers — The ISO control's requirement for a documented cryptographic policy and lifecycle directly implements the ASVS mandate for a documented key-management policy and lifecycle.
- V11.1.2mostlycovers — Mandating an inventory of algorithms, keys and certificates satisfies the ASVS requirement to maintain and regularly update a cryptographic inventory.
- V11.2.1partialaligns with — Specifying approved algorithms, cipher strength and usage practices aligns with the ASVS requirement to use industry-validated cryptographic implementations.
- V11.2.2partialaligns with — The ISO control's emphasis on standards, approved algorithms and key-management procedures supports the ASVS goal of designing for crypto-agility.
- V13.3.1partialaligns with — Requiring secure generation, storage, distribution and destruction of keys aligns with the ASVS requirement to use a secrets-management solution for cryptographic material.
- V13.3.4partialaligns with — Defining key rotation, revocation and archival processes aligns with the ASVS requirement that secrets be configured to expire and be rotated according to documented policy.
Related weaknesses / CWE (152)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
CWE-1204←P →MCWE-1230←PCWE-1240←M →MCWE-1241←P →PCWE-1255←P →PCWE-1258←PCWE-1270←P →PCWE-1279←P →PCWE-1291←P →PCWE-1323←P →PCWE-1394←P →MCWE-202←P →PCWE-256←P →MCWE-257←PCWE-260→PCWE-261→MCWE-290←P →PCWE-294←P →MCWE-295→PCWE-296←P →MCWE-297←P →PCWE-298←P →PCWE-299←P →MCWE-300←P →MCWE-301→PCWE-303←PCWE-313←P →FCWE-314←P →FCWE-315←P →FCWE-316←P →PCWE-317←P →PCWE-318←P →MCWE-321→PCWE-322←P →MCWE-323←P →MCWE-324←P →MCWE-325←PCWE-326→PCWE-327→MCWE-328←P →MCWE-329←P →FCWE-330←P →MCWE-331←P →MCWE-332←P →PCWE-333←P →PCWE-334←P →MCWE-335←P →PCWE-336←P →PCWE-337←P →PCWE-338←P →MCWE-339←P →PCWE-340←P →MCWE-341←P →MCWE-342←P →PCWE-343←P →PCWE-345←P →PCWE-347→PCWE-353←P →MCWE-354←P →MCWE-358←P →PCWE-360←P →PCWE-370←P →PCWE-419→PCWE-5←P →FCWE-515←PCWE-522→MCWE-523→MCWE-524→PCWE-526←P →MCWE-539←PCWE-555→PCWE-591←PCWE-599←P →PCWE-614→PCWE-649←P →PCWE-656←P →MCWE-757←P →PCWE-759←P →MCWE-760←P →MCWE-780←P →MCWE-798→PCWE-836←PCWE-916→PCWE-923→PCWE-924←P →MCWE-940→P
Why these map — AI rationale (under review)
- CWE-1230nonemitigates — Cryptographic controls can protect metadata confidentiality, but the control is broader in scope.
- CWE-1326nonemitigates — Cryptographic controls can protect the root of trust but do not mandate its hardware immutability.
- CWE-257nonemitigates — Requires proper use of cryptography, which can mitigate recoverable storage if applied correctly to passwords.
- CWE-346nonemitigates — Cryptography can support origin validation when used for authentication but is not the control's primary intent.
- CWE-348nonemitigates — Cryptographic controls can verify source authenticity and integrity, thereby mitigating the weakness.
- CWE-402nonemitigates — Cryptography can protect data in transit but does not stop the product from sending it to the wrong party.
- CWE-420nonemitigates — Cryptography can protect alternate channels but does not address the policy of applying equal protection across channels.
- CWE-1204prevents — Mandates correct use of cryptography, directly requiring strong, unpredictable IV generation for primitives that need it.
- CWE-1240prevents — Mandates approved cryptographic controls, directly preventing use of risky or non-compliant implementations.
- CWE-1241prevents — Mandates use of approved cryptographic algorithms and RNGs, directly preventing predictable PRNGs.
- CWE-1255mitigates — Cryptographic implementation guidance can require constant-time or masked algorithms that reduce power side-channel leakage during token comparison.
- CWE-1270prevents — Proper use of cryptography ensures tokens are generated with correct algorithms, keys and entropy.
- CWE-1279prevents — Mandates proper use of cryptography, which includes ensuring supporting units are ready before operations.
- CWE-1291prevents — Cryptographic key-management rules would normally require separate keys for debug vs. production signing.
- CWE-1323prevents — Cryptography can be applied to encrypt trace data at rest or in transit.
- CWE-1394prevents — Mandates proper key management, directly preventing use of default cryptographic keys.
- CWE-202mitigates — Cryptography can protect data at rest or in transit, limiting exposure even if inference occurs.
- CWE-256prevents — Requires use of cryptography to protect sensitive data such as passwords at rest.
- CWE-260mitigates — Cryptographic controls can protect stored credentials, but do not address the root practice of embedding passwords in files.
- CWE-261prevents — Requires appropriate use of cryptography, indirectly discouraging weak encoding schemes.
- CWE-290prevents — Cryptography supports authentication but does not guarantee correct implementation against spoofing.
- CWE-294prevents — Cryptographic protections (e.g., nonces, timestamps, message authentication codes) make captured authentication messages unusable for replay.
- CWE-295prevents — Requiring issuance and validation of public-key certificates under an approved policy reduces the chance that certificates with improper validation will be trusted.
- CWE-296prevents — Mandates proper use of cryptography including certificate validation and trusted roots.
- CWE-297prevents — Use of cryptography mandates correct implementation of certificate validation and hostname verification.
- CWE-298prevents — Cryptography policy requires proper certificate lifecycle management including expiration validation.
- CWE-299prevents — Mandates use of cryptography including certificate validation and revocation checking.
- CWE-300prevents — Cryptography provides channel integrity and can support endpoint authentication.
- CWE-301prevents — Cryptographic controls can underpin stronger authentication protocols but do not by themselves prevent reflection attacks.
- CWE-313prevents — Cryptography control directly mandates encryption of sensitive data at rest.
- CWE-314prevents — Cryptographic controls directly prevent cleartext storage of sensitive registry data.
- CWE-315prevents — Mandates use of cryptography to protect sensitive data, directly preventing cleartext cookie storage.
- CWE-316prevents — Cryptographic controls can mandate encryption of sensitive data in memory, directly reducing cleartext exposure.
- CWE-317prevents — Cryptography can protect data at rest/display, but does not mandate GUI-level masking.
- CWE-318prevents — Cryptographic controls directly prevent cleartext storage of sensitive data in executables.
- CWE-321prevents — Key-management controls that govern generation, rotation and protection of keys make the use of embedded hard-coded cryptographic keys less likely and easier to detect.
- CWE-322prevents — Use of cryptography mandates authenticated key-exchange mechanisms, directly addressing the lack of entity authentication.
- CWE-323prevents — Mandates proper cryptographic key and nonce management, directly preventing nonce/key-pair reuse.
- CWE-324prevents — Use-of-cryptography control explicitly covers key lifecycle management including expiration and rotation.
- CWE-326prevents — Requiring the organization to define and enforce minimum cryptographic strength prevents deployment of insufficient key lengths or weak ciphers that can be brute-forced.
- CWE-327prevents — Mandating approved algorithms, cipher strength and usage standards directly stops the selection of broken or weak cryptographic primitives that attackers can exploit.
- CWE-328prevents — Mandates use of approved cryptographic algorithms, directly preventing weak-hash selection.
- CWE-329prevents — Mandates proper cryptographic controls including IV generation, directly preventing predictable-IV CBC weaknesses.
- CWE-330prevents — Cryptographic controls require use of approved, sufficiently random values for keys and nonces.
- CWE-331prevents — Mandates use of cryptography that must rely on sufficient entropy sources.
- CWE-332prevents — Mandates use of cryptography that must rely on cryptographically strong RNGs, directly addressing insufficient entropy.
- CWE-333prevents — Mandates proper cryptographic key generation and entropy sources, directly addressing insufficient TRNG entropy.
- CWE-334prevents — Cryptographic controls require adequate key/seed entropy, directly mitigating small random-value spaces.
- CWE-335prevents — Cryptography policy and key-management rules directly require proper seeding of PRNGs used for keys and nonces.
- CWE-336prevents — Cryptography policy and key-management requirements directly mandate proper PRNG seeding and entropy sources.
- CWE-337prevents — Mandates use of cryptography, which includes selecting and seeding PRNGs with sufficient entropy.
- CWE-338prevents — Mandates use of approved cryptographic controls, directly requiring cryptographically strong RNGs.
- CWE-339prevents — Mandates use of cryptography that must rely on cryptographically strong PRNGs with adequate seed entropy.
- CWE-340prevents — Cryptographic controls require use of approved, sufficiently random algorithms and key-generation methods, directly mitigating predictable number/identifier weaknesses.
- CWE-341prevents — Cryptographic controls replace predictable values with high-entropy, non-guessable material.
- CWE-342prevents — Cryptographic controls require use of approved, unpredictable RNGs, directly mitigating predictable-value weaknesses.
- CWE-343prevents — Cryptographic controls require use of approved, unpredictable RNGs, directly mitigating predictable value sequences.
- CWE-345prevents — Cryptographic mechanisms directly verify data origin and integrity, preventing acceptance of unauthentic data.
- CWE-347prevents — Establishing approved cryptographic solutions and usage practices lowers the probability that signature-verification steps will be omitted or incorrectly implemented.
- CWE-353prevents — Cryptographic controls can provide integrity verification for transmitted data.
- CWE-354prevents — Cryptographic controls mandate integrity mechanisms whose correct validation directly prevents CWE-354.
- CWE-358prevents — Use of cryptography control depends on correct implementation of standardized cryptographic checks.
- CWE-360prevents — Cryptography can protect event integrity and authenticity but is not explicitly required by the control for this purpose.
- CWE-370mitigates — Use of cryptography includes certificate lifecycle management, yet does not mandate continuous revocation status verification.
- CWE-419prevents — Cryptography can protect confidentiality and integrity of the primary channel.
- CWE-5prevents — Directly requires use of cryptography to protect data confidentiality and integrity during transmission.
- CWE-522prevents — Protecting secret and private keys against disclosure and unauthorized use decreases the exposure of credentials that are stored or transmitted in recoverable form.
- CWE-523prevents — Requires use of cryptography, directly enabling encryption of credentials in transit.
- CWE-524mitigates — Cryptography can protect cached data at rest, but does not address access control scope.
- CWE-526prevents — Cryptography control directly addresses the lack of encryption for sensitive data stored in environment variables.
- CWE-555prevents — Requires cryptographic protection of sensitive data, which can mitigate plaintext password storage when applied to credentials.
- CWE-599prevents — Mandates proper use of cryptography including certificate validation, directly addressing the missing SSL_get_verify_result() check.
- CWE-614mitigates — Use of cryptography control mandates encryption in transit, which HTTPS provides, but does not specifically require the Secure cookie attribute.
- CWE-649prevents — Cryptographic controls must include integrity mechanisms (e.g., MACs, signatures) to detect tampering of protected data.
- CWE-656prevents — Mandates use of cryptography whose strength is independent of secrecy of design or keys.
- CWE-757prevents — Mandates use of strong, approved cryptographic algorithms, directly preventing downgrade to weaker ones.
- CWE-759prevents — Use of cryptography requires appropriate cryptographic controls including salting for password hashing.
- CWE-760prevents — Use of cryptography requires appropriate cryptographic controls including proper salting, largely mitigating predictable-salt weaknesses.
- CWE-780prevents — Mandates proper use of cryptography, directly requiring OAEP with RSA.
- CWE-798mitigates — Secure key-generation, distribution and storage procedures reduce the likelihood that hard-coded or default cryptographic keys will be introduced or left unprotected.
- CWE-916prevents — Requires appropriate use of cryptography, which encompasses selecting strong hashing algorithms for passwords.
- CWE-923prevents — Cryptography can protect channels but does not guarantee correct endpoint identity without additional controls.
- CWE-924prevents — Cryptography is the primary technical means to enforce message integrity during transmission.
- CWE-940prevents — Cryptography can support channel authentication but does not inherently verify source without proper implementation.
Mitigated MITRE ATT&CK techniques (284)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
T1001←MT1001.001←MT1001.002←MT1001.003←MT1006←MT1011←MT1014←MT1021.004→PT1027→PT1027.001←MT1027.002←MT1027.003←MT1027.005←MT1027.006←MT1027.007←MT1027.008←MT1027.009←MT1027.010←MT1027.011←PT1027.012←MT1027.013←MT1027.014←MT1027.015←MT1027.016←MT1027.017←MT1027.018←MT1030←MT1036←MT1036.003←MT1036.005←MT1036.008←MT1036.009←PT1040→MT1041→PT1048→PT1048.001→PT1048.003←M →PT1052←MT1055←M →PT1055.001←MT1055.002←MT1055.003←M →PT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1068←PT1070←MT1071.001←MT1071.004←MT1071.005←MT1078←P →PT1090←MT1090.002←MT1090.003←MT1090.004←MT1095←MT1098.001←MT1098.004←MT1098.005←MT1102←MT1102.001←MT1102.002←MT1102.003←MT1110→MT1110.001→MT1110.002→MT1110.003→MT1110.004→MT1111←M →PT1127←MT1127.001←MT1132←PT1132.001←MT1132.002←MT1133←MT1134←MT1185←MT1204.004←PT1205←PT1207←MT1211←PT1216←MT1218←MT1218.005←MT1218.007←MT1218.008←MT1218.009←MT1218.010←MT1218.011←PT1218.012←MT1218.013←MT1219.003←MT1220←PT1221←PT1222.002←MT1480.001←MT1484←PT1484.002←PT1485→PT1486→MT1490←MT1497←PT1499.002←PT1528→PT1530→PT1535←MT1537←MT1539←F →PT1542←MT1542.002←MT1542.003←MT1548←PT1550←FT1550.001←FT1550.002←FT1550.003←F →PT1550.004←FT1552←M →PT1552.001←P →PT1552.004→PT1553←P →PT1553.001←MT1553.002←PT1553.003←MT1553.004←MT1553.005←PT1553.006←MT1555→PT1555.001←M →PT1555.002←PT1555.003←MT1555.004→PT1555.005←P →PT1555.006←M →PT1556←MT1556.001←MT1556.003←PT1556.005←P →PT1556.006←MT1556.007←MT1556.008←MT1556.009←MT1557←M →MT1557.004←M →PT1558←M →PT1558.001←PT1558.002←MT1558.003→PT1558.004→PT1560←P →PT1561→PT1561.001→MT1561.002→MT1565→PT1565.001→PT1565.002←P →PT1567.004←PT1568.003←MT1571←MT1572←M →PT1573←MT1573.001→PT1573.002→PT1574←PT1574.001←MT1574.004←MT1574.013←MT1578←PT1578.002←MT1578.003←MT1578.004←MT1588.004←PT1589.001→PT1599←MT1599.001←PT1600←M →PT1600.001→MT1600.002←MT1601.001←MT1601.002←MT1606←MT1606.001←F →PT1606.002←M →PT1610←PT1612←PT1620←MT1621←M →MT1622←MT1647←PT1649→PT1665←PT1666←PT1678←PT1684.002→PT1685←MT1685.002←MT1685.003←PT1685.004←MT1685.005←MT1686←FT1686.001←MT1686.003←MT1687←PT1688←MT1689←M
Why these map — AI rationale (under review)
- T1021.004prevents — A.8.24 requires proper cryptography (algorithms, key management, strength, approved practices) for protecting authenticity/integrity of remote access including SSH keypairs, which directly stops the public-key authentication path of this technique when followed; the bounded remainder is password-based SSH auth that does not rely on cryptography.
- T1027prevents — A.8.24 mandates approved cryptographic algorithms, key management and usage rules that can prevent certain classes of encryption-based obfuscation (e.g. weak or prohibited ciphers for payloads in transit or at rest) but does not stop encoding, compression, splitting, command obfuscation or other non-cryptographic forms of T1027.
- T1040prevents — Requiring encryption of data in transit and proper key protection reduces the value an attacker gains from passively capturing network packets.
- T1041detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities, which can surface anomalous exfiltration patterns hidden in C2 traffic when those controls or logs are in scope; this is only a slice because the clause governs cryptography usage rather than mandating broad network or protocol anomaly detection.
- T1048detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection, content filtering) and mandates logging/auditing of key-management activities, which can surface anomalous use of encrypted alternate protocols; this is only a minority slice of the broad technique that also covers unencrypted channels, non-crypto utilities, and direct cloud-console downloads.
- T1048.001detects — A.8.24 requires monitoring/auditing of key management activities and consideration of cryptography's impact on content-inspection controls (e.g. malware detection), which can surface anomalous use of symmetric encryption for exfiltration as a side effect, but the clause's core focus is proper implementation and key handling rather than broad detection of adversary TTPs.
- T1048.003detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities, which can surface anomalous unencrypted exfiltration as a policy or configuration deviation; this is only a minority slice of the technique because the clause governs cryptography usage rather than mandating network or protocol anomaly detection.
- T1048.003prevents — A.8.24 requires identifying protection needs, mandating appropriate cryptography (including for data in transit over networks), and adopting approved algorithms/strengths; this directly stops unencrypted exfiltration by forcing encryption on sensitive data flows, but remains partial because the control is scoped to organization-defined requirements and classification (allowing unencrypted flows for data not deemed sensitive) and does not govern all possible non-C2 protocols or adversary-chosen alternate locations.
- T1055detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates cryptographic solutions that can be audited/logged, which surfaces some process-injection attempts that rely on or interact with encrypted payloads or keys, but the clause does not mandate or perform detection of the injection technique itself.
- T1055.003detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities; this surfaces anomalies tied to encrypted payloads or key misuse that can accompany thread hijacking, but the clause does not mandate host/process behavioral monitoring that would catch the core SuspendThread/WriteProcessMemory/SetThreadContext sequence itself.
- T1078prevents — A.8.24 mandates strong cryptography (including for authentication, key management, and endpoint/storage protection) which can stop credential compromise or abuse in specific slices such as network transit, stored secrets, or weak auth protocols, but leaves the bulk of the technique (e.g. phishing, inactive accounts, local privilege overlap, non-crypto auth) untouched.
- T1110prevents — A.8.24 mandates appropriate cryptographic strength, key management, and MFA-capable authentication mechanisms (via policy and approved standards) that stop offline brute-force on hashes and most online guessing; the named remainder is legacy or exempted accounts that still rely on weak single-factor secrets.
- T1110.001prevents — A.8.24 requires appropriate cryptographic authentication (e.g. MFA, strong algorithms, key management) that stops password guessing from yielding access on covered services and endpoints; the named remainder is exempted identities, legacy protocols, and non-cryptographic paths the clause itself acknowledges.
- T1110.002prevents — A.8.24 mandates appropriate cryptographic algorithms, key management and strength calibrated to data classification; where password hashes use approved strong, salted, slow KDFs the cracking technique is prevented from recovering usable plaintext, with the bounded remainder being weak/legacy hashes or non-cryptographic storage that the clause's own guidance on classification and approved algorithms leaves nameable.
- T1110.003prevents — A.8.24 mandates appropriate cryptographic strength, key management, and usage rules (including for authentication protocols and endpoints); where this results in strong MFA, encrypted channels, or password-hashing that defeats cleartext spraying, the technique cannot succeed — matching the A.8.5→T1110.001 anchor — but exemptions, legacy protocols, and non-crypto vectors leave a bounded remainder.
- T1110.004prevents — A.8.24 mandates appropriate cryptographic protection (including strong auth mechanisms such as MFA or cryptographic tokens) proportionate to data classification and risk, which stops credential-stuffing attacks from succeeding on covered services and accounts; the named remainder is legacy protocols, exempted identities, or static secrets that bypass the mandated cryptography.
- T1111prevents — A.8.24 requires appropriate cryptography (including key management and strength) for protecting credentials and transmitted MFA factors such as one-time codes; this stops some interception vectors (e.g. plaintext SMS/email, weak token crypto) but leaves keyloggers, hardware-token proxying, seed compromise, and out-of-band device compromise untouched.
- T1485recovers — A.8.24's key management explicitly requires secure backup/archiving of keys plus recovery of encrypted information in case of lost, compromised or damaged keys, directly enabling restoration of availability for data destroyed via encryption-based destruction (a common real-world vector for T1485) while leaving non-crypto deletion cases as named remainder.
- T1486recovers — A.8.24's key management explicitly requires processes for recovering encrypted information in the case of lost, compromised or damaged keys, directly enabling restoration of availability after ransomware encryption (the named remainder is data for which no recoverable key was retained).
- T1528prevents — A.8.24 requires proper cryptography (including key management, strength, and protection of secrets) for confidentiality/integrity/authenticity per policy; this can prevent some token-theft vectors (e.g. weak transmission, poor key handling for OAuth/JWTs, or unencrypted storage) but leaves the dominant social-engineering, compromised-container, and post-auth token-abuse slices untouched.
- T1530prevents — A.8.24 mandates use of cryptography (algorithms, key management, strength per classification) to protect confidentiality of information including data at rest in cloud storage, which directly stops the technique when the data is encrypted and the adversary lacks the key; it is only partial because the control governs cryptography where used rather than mandating encryption for all cloud objects (misconfigurations and credential abuse can still yield plaintext access).
- T1539prevents — A.8.24 requires protecting confidentiality/integrity of information (including in transit and on endpoints) via appropriate cryptography and key management; this can prevent cookie theft from network traffic or at-rest storage via encryption (and related practices), but leaves the dominant vectors (in-memory theft, malicious JS injection, proxy/AitM frameworks, malware scraping) untouched.
- T1550.003prevents — A.8.24 mandates proper key management, algorithm strength, and protection of keys (including against compromise, loss, or unauthorized use) which can prevent generation or successful use of forged Golden/Silver tickets and overpass-the-hash variants that rely on stolen/weak keys, but leaves the core PtT technique (reusing already-stolen valid tickets obtained via credential dumping) untouched.
- T1552prevents — Enforcing encryption of sensitive information on endpoints and storage media limits an attacker’s ability to locate and read credentials stored in files or configuration stores.
- T1552.001prevents — A.8.24 requires identifying protection needs then mandating appropriate cryptography (including for data at rest on devices/storage and in transit), which directly stops many classes of insecure plaintext credential storage in files; it leaves the remainder of non-crypto cases (e.g. OS-protected stores, misconfigured access controls on already-encrypted files, or credentials embedded in code that never reach a protected store).
- T1552.004prevents — A.8.24 mandates proper key generation, protection, storage, access controls, and usage practices that stop many insecure-storage cases (and therefore the search), but leaves residual exposure from implementation gaps, legacy keys, or keys already present before the control applies.
- T1553prevents — A.8.24 requires approved cryptographic standards, key management, and proper use of signing/encryption to establish trust (e.g. valid code signing certificates), which directly stops some subversions that rely on weak, stolen, or improperly managed keys; it does not address non-crypto trust controls, attribute modification, or registry changes that enable the technique.
- T1555prevents — A.8.24 requires identifying protection levels, selecting appropriate cryptography/strength, and protecting keys/storage/transmission (including on endpoints and in vaults), which can prevent plaintext credential extraction from many common stores; however, it does not mandate encryption for all password stores or block all search-based extraction methods, leaving a genuine slice unreached.
- T1555.001prevents — A.8.24 mandates proper key management (generation, protection, storage, rotation, revocation) and approved cryptographic practices that, when applied to credentials stored in the Keychain, stop many common extraction paths (e.g., by enforcing strong protection of the master password, key wrapping, or hardware-backed keys); however, the control is silent on the specific macOS Keychain implementation details, default user-password equivalence, and non-cryptographic access vectors such as memory scraping or unlocked-session dumping, leaving a substantial slice of the technique reachable.
- T1555.004prevents — A.8.24 requires proper cryptography (including key management and strength) for protecting stored credentials; this can stop plaintext recovery or weak encryption of .vcrd/Policy.vpol files, but the technique also covers non-crypto vectors such as vaultcmd.exe enumeration, direct API abuse (CredEnumerateA), and GUI backup extraction that cryptography does not block.
- T1555.005prevents — A.8.24 mandates proper cryptography (including key management and strength) for protecting stored credentials; this directly stops the encrypted-database slice of the technique when the password manager follows the rules, but leaves memory extraction after unlock, brute-force of the master password, and non-compliant implementations untouched.
- T1555.006detects — A.8.24's key-management logging/auditing and consideration of controls that rely on content inspection (e.g. malware detection) can surface anomalous access or use of secrets managers, but this is scoped only to cryptographic-key activities rather than the broader technique of privileged API retrieval of any credential material.
- T1556.005detects — A.8.24's key-management logging/auditing and consideration of encrypted-information impacts on content-inspection controls (e.g. malware detection) can surface anomalous reversible-encryption settings or related credential-access activity, but this is incidental and not required by the clause's core purpose of proper cryptographic use.
- T1557prevents — Mandating approved cryptographic algorithms and key-management procedures for network traffic makes it harder for an adversary to intercept and manipulate traffic in order to steal credentials.
- T1557.004prevents — A.8.24 requires proper cryptography (including certificates, key management, and protection of transmitted data) that can stop evil twin MITM from succeeding on HTTPS traffic via custom certs or weak encryption, but the core technique of spoofing SSIDs, stronger signals, or probe responses to induce connection happens before any crypto is applied and is not addressed by the control.
- T1558detects — A.8.24's key-management logging/auditing and consideration of encrypted-information impacts on content inspection (e.g. malware detection) can surface anomalous Kerberos ticket activity or related artifacts, but this is limited to specific cryptographic-use cases rather than broadly detecting ticket theft or forgery across platforms.
- T1558prevents — A.8.24 requires proper key management, algorithm strength, and protection of keys (including against compromise, loss, or unauthorized use), which directly prevents many forgery and theft vectors for Kerberos tickets that rely on weak keys, poor key handling, or exposed long-term keys; however, it does not address all ticket-stealing methods such as memory scraping of valid TGTs or protocol abuses that do not involve key compromise.
- T1558.003prevents — A.8.24 requires approved strong cryptography, key management, and consideration of algorithm strength; mandating modern ciphers (e.g., AES over RC4) for Kerberos would stop etype 23 TGS tickets from being issued, preventing the vulnerable hash from existing and thus the offline brute-force technique, but this is only a slice because the control sets requirements rather than universally enforcing removal of RC4 support or weak SPN configurations across all environments.
- T1558.004prevents — A.8.24 requires approved strong algorithms, key management, and protection of authentication data in transit/storage; this directly stops the insecure (e.g. RC4) encryption of AS-REP messages that the technique relies on, but only for systems built under the control and leaves a remainder where pre-auth is disabled or legacy weak crypto is still permitted.
- T1560detects — A.8.24's key-management logging/auditing and impact considerations on content-inspection controls (e.g. malware detection) can surface anomalous cryptographic use or encrypted blobs that match T1560's pre-exfil artifact, but the clause is scoped to approved organizational cryptography rather than broadly detecting adversary compression/encryption of arbitrary collected data.
- T1561recovers — A.8.24's key management explicitly requires backing up/archiving keys and recovering encrypted information in case of lost, compromised or damaged keys, which directly enables recovery from a disk-wipe that has destroyed key material or rendered encrypted volumes inaccessible; this is only a slice of the full technique (arbitrary sector/MBR wipes, config erasure on network devices, worm-like propagation) so the extent is partial rather than mostly or full.
- T1561.001recovers — A.8.24's key-management guidance explicitly requires processes for recovering encrypted information in the case of lost, compromised or damaged keys, and for backing up/archiving keys; this directly restores availability of data rendered irrecoverable by disk-content wipe when that data had been protected by organization-approved cryptography.
- T1561.002recovers — A.8.24's key management explicitly requires secure backup/archiving of keys plus recovery of encrypted information when keys are lost, compromised or damaged; this directly restores availability after a disk-structure wipe that renders encrypted volumes or boot-critical encrypted structures unusable.
- T1565prevents — A.8.24 mandates cryptographic protection of integrity (and authenticity) for information at rest/transit per policy and classification, which directly stops many classes of unauthorized insertion/deletion/manipulation that would otherwise succeed; it leaves open non-cryptographic vectors, insider-authorized changes, and post-decryption manipulation.
- T1565.001prevents — A.8.24 mandates use of cryptography (with appropriate strength, key management, etc.) to protect integrity of information at rest; this directly prevents many forms of stored-data manipulation by rendering unauthorized modification detectable or infeasible, but leaves a genuine slice unaddressed (e.g., manipulation before encryption, insider-authorized changes, or non-cryptographically-protected data stores).
- T1565.002detects — A.8.24's key-management logging/auditing and consideration of encrypted-data impact on content-inspection controls (e.g. malware detection) can surface anomalous cryptographic or transmission behavior, but the clause's core focus is proper use and protection rather than mandating detection of in-transit manipulation.
- T1565.002prevents — A.8.24 mandates use of cryptography (algorithms, key management, strength) to protect integrity of information in transit per requirements, which directly stops alteration of transmitted data where encryption, MACs or signatures are applied; partial because the clause sets requirements rather than a universal mechanism (implementation scope, non-crypto channels, and cases where integrity protection is not selected leave a slice uncovered).
- T1572prevents — A.8.24 mandates approved cryptographic algorithms, key management and usage rules that can legitimately prevent classes of unauthorized tunneling (e.g. requiring only organization-approved SSH/DoH configurations with managed keys and no unauthorized outer-layer encryption), but leaves many tunneling variants (custom protocols, non-crypto encapsulation, approved-but-abused tunnels) untouched.
- T1573.001detects — A.8.24's key management, logging/auditing of crypto activities, and consideration of impact on content inspection (e.g. malware detection) can surface anomalous or non-compliant use of symmetric crypto in C2 traffic, but this is limited to cases where the implementation falls inside the organization's approved standards rather than the technique itself.
- T1573.002prevents — A.8.24 mandates approved cryptographic standards, algorithms, key management and usage rules that, when followed, stop adversaries from employing weak or non-standard asymmetric crypto for C2; however the control only governs what the organization itself deploys and does not block an adversary from choosing strong, standards-compliant asymmetric crypto (e.g. TLS) for their own C2 channel.
- T1589.001prevents — A.8.24 mandates proper cryptography (including key management, strength selection, and MFA-supporting auth) that stops many credential-gathering vectors such as weak storage, transit exposure, or insufficient MFA, but leaves open elicitation, leaks of already-encrypted data, dark-web purchases, and infostealer logs.
- T1600prevents — A.8.24 requires approved cryptographic standards, key management, and strength selection that would stop many weakening vectors (e.g. weak ciphers, poor key generation, disabled hardware) on devices built under it, but does not reach post-deployment compromise of already-deployed network devices or their images.
- T1600.001detects — A.8.24 requires logging/auditing of key management activities plus consideration of cryptography's impact on content inspection controls; this can surface anomalous key-size or cipher-strength changes on managed devices as part of key-management monitoring, but the clause does not mandate network or device telemetry that would catch the technique in general use.
- T1600.001prevents — A.8.24 requires selecting, mandating and enforcing approved cryptographic algorithms, cipher strength, key sizes and usage practices (including via topic-specific policy and standards), which directly stops the technique of deliberately weakening key space on managed devices; the bounded remainder is post-compromise modification of already-deployed images that bypass policy enforcement.
- T1606.001prevents — A.8.24 mandates proper cryptographic practices including key management, algorithm strength, and protection of secrets; this directly constrains the cryptographic seed values/private keys required to forge valid cookies, but leaves non-crypto forgery vectors, weak implementations, and legacy/legacy-exempt cookie schemes as an open slice.
- T1606.002prevents — A.8.24 requires proper key management, algorithm strength, and approved cryptographic practices that directly stop an adversary from obtaining or forging with a valid token-signing certificate when those rules are followed; the remainder is the case where the adversary can establish their own trusted certificate via sufficient permissions, which the clause does not address.
- T1621prevents — A.8.24 requires appropriate strength and MFA-appropriate authentication techniques (including push, SMS, app-based) proportionate to data classification, directly preventing the generation of weak or fatigue-vulnerable MFA requests from succeeding in granting access.
- T1649prevents — A.8.24's key-management rules (generation, protection, storage, revocation, destruction, and handling of compromised keys) directly constrain the theft of private keys from storage or the CA and the forging of golden certificates, but the control is silent on enrollment-rights hygiene, SAN/EKU misconfigurations, and certificate misuse after issuance, leaving a large remainder of the technique reachable.
- T1684.002prevents — A.8.24 requires use of cryptography (including DKIM digital signatures for email integrity/authenticity) per policy and standards, which when enforced prevents header-spoofing that would otherwise pass authentication; it does not govern non-crypto vectors such as Direct Send, weak/absent DMARC policy, or SPF-only failures.
Prevented OWASP Web Top 10 (2025) risks (5)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A04mitigates — A.8.24 governs proper use of cryptography (algorithms, key management, strength) where applied, which bounds the realized impact of weak/misused crypto (e.g. by making ciphertext unreadable) without addressing absent cryptography or all usage sites.
- A04prevents — A.8.24's purpose and guidance directly mandate identifying protection needs then selecting/using appropriate algorithms, key management, and approved practices, which closes the bulk of absent/weak/misused cryptography that the A04 class names; the bounded remainder is legacy data already at rest with no re-encryption trigger and cases where the approved algorithm is later broken.
- A05mitigates — A.8.24's encryption of data in transit or at rest (and its impact note on content inspection) bounds the consequence of some injection families (e.g. outbound C2/exfil from OS/command injection or SSRF) but leaves the injection itself and in-band families (SQLi, XSS) untouched.
- A08mitigates — A.8.24's cryptographic mechanisms (signing, hashing, authenticated encryption) can bound the consequences of unsigned updates or unverified deserialization when those failures cross into confidentiality/authenticity/integrity violations, but the control does not address CI/CD pipeline compromise or the core 'trust without verification' decision itself.
- A09mitigates — A.8.24's encryption of logs (via its confidentiality/integrity purpose and key-management rules) bounds the consequence of realized logging failures by protecting log contents from tampering or unauthorized reading, without addressing the absence of logging/alerting itself.
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.