A.5.16 Organizational
Identity management
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 (21)
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)
- AC-2mostlyaligns with — Both controls require formal account lifecycle management, including approval, timely disabling or removal, and oversight of shared or non-human accounts.
- AC-2mostlycovers — A.5.16's identity management requirement (unique identification + assignment of access rights) accounts for the bulk of ac-2's account lifecycle, user/group/role/access authorization, and privilege specification; a real residual remains on ac-2's explicit account-type allow/prohibit lists, account-manager assignment, and formal approval workflows.
- IA-2mostlycovers — A.5.16's identity management requirement (unique identification + access rights assignment) accounts for the bulk of IA-2's organizational-user identification mandate, but leaves a residual on the explicit authentication and process-association aspects that sit outside A.5.16's defined scope.
- IA-4mostlyaligns with — Both controls establish rules for creating, assigning, and retiring unique identifiers so that each identity remains attributable to a single entity and is removed when no longer needed.
- IA-4mostlycovers — A.5.16's requirement for unique identification and appropriate access rights assignment accounts for the bulk of IA-4's identifier lifecycle (receive auth, select, assign, prevent reuse), but leaves a residual on explicit group/role/service/device identifier handling and the parameter-driven authorization step that 27002 does not detail at the same granularity.
- IA-8mostlycovers — A.5.16's identity management requirement (unique identification + access rights assignment) accounts for the bulk of IA-8's non-org user identification/authentication needs, but leaves a residual on the authentication mechanisms and processes specific to external users that IA-8 explicitly requires.
- AU-2partialaligns with — The ISO mandate to retain records of significant identity-management events aligns with NIST’s requirement to log events that are necessary for accountability and incident review.
- IA-2partialaligns with — The ISO requirement that each identity be linked to one person supports the NIST objective of binding organizational-user identities to authenticated subjects before access is granted.
- IA-8partialaligns with — Both controls address the acceptance and risk treatment of identities issued by external parties when those identities are used for organizational access.
Aligned NIST CSF 2.0 outcomes (16)
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.AA-01mostlycovers — The ISO control's emphasis on unique, accountable identities, timely removal, and oversight of non-human identities directly implements the CSF outcome of managing identities and credentials for authorized users, services, and hardware.
- PR.AA-02mostlyaligns with — Re-verification of trusted documents and ensuring third-party identities meet required trust levels align with the CSF outcome of proofing identities and binding them to credentials based on interaction context.
- GV.SC-02partialaligns with — The requirement to assess and treat risks when accepting third-party identities aligns with the CSF outcome of establishing and coordinating cybersecurity roles and responsibilities for suppliers and partners.
- ID.AM-08partialaligns with — Timely disabling or removal of identities when entities or roles change supports the CSF outcome of managing systems, hardware, software, services, and data throughout their life cycles.
- PR.AA-05partialaligns with — Dedicated approval, documentation, and segregation of duties for shared or non-human identities support the CSF outcome of defining, managing, and reviewing access permissions and authorizations.
- GV.SC-02implements — 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.AM-08implements — 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.AA-02implements — A.5.16's core purpose of unique identification and enabling access rights directly operationalizes the identity-proofing and binding outcome in PR.AA-02 within the access/identity domain
- PR.AA-05implements — A.5.16 directly operationalizes the identity foundation required for PR.AA-05's defined/managed/enforced access permissions (unique identification + assignment of rights is the concrete technical means that gives effect to the governance outcome).
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)
- V6.3.2fullcovers — The ISO requirement to disable or remove identities that are no longer required directly implements the ASVS mandate to ensure default or unused accounts are disabled.
- V6.8.1mostlyaligns with — Requiring that third-party identities meet an appropriate trust level and that risks are treated aligns with the ASVS requirement to prevent identity spoofing across multiple identity providers.
- V6.1.3partialaligns with — Documenting and approving shared or non-human identities and their controls supports the ASVS expectation that all authentication pathways and their security controls are documented.
- V6.3.4partialaligns with — Mandating approval, documentation, and oversight for shared or non-human identities helps ensure there are no undocumented authentication pathways.
- V7.4.2partialaligns with — Timely removal of identities when a person leaves or changes role supports the ASVS requirement to terminate all active sessions upon account disablement or deletion.
Related weaknesses / CWE (24)
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).
Why these map — AI rationale (under review)
- CWE-269noneprevents — Enforcing documented approval and independent oversight for non-person identities limits the assignment of excessive privileges that could be abused.
- CWE-284prevents — Requiring one-to-one mapping of identities to entities and timely removal of unused identities directly stops attackers from leveraging stale or shared accounts to bypass access restrictions.
- CWE-286prevents — Identity management directly governs the full lifecycle of user accounts, preventing incorrect user management.
- CWE-287prevents — Mandating segregated approval and oversight for non-human identities reduces the chance that weak or orphaned credentials can be exploited for unauthorized authentication.
- CWE-289prevents — Identity-management processes can require unique, canonical identifiers, reducing alternate-name bypass risk.
- CWE-290prevents — Identity management supports unique identities but does not guarantee resistance to spoofing.
- CWE-291prevents — Identity-management processes should replace IP-based identification with verified identities.
- CWE-322prevents — Identity management provides the verified identities required before key exchange occurs.
- CWE-441prevents — Proper identity management ensures the original requester identity is preserved and validated before the product forwards requests.
- CWE-694prevents — Identity management processes that enforce unique identifiers directly prevent duplicate resource IDs.
Mitigated MITRE ATT&CK techniques (420)
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.003←MT1003→PT1003.001←PT1003.006→PT1003.008←PT1006←MT1014←MT1021←P →PT1021.001←P →PT1021.002←P →PT1021.003→PT1021.004←P →MT1021.005→PT1021.006←P →PT1021.007←M →PT1021.008←P →PT1027.011←PT1027.014←MT1036←MT1036.002←MT1036.003←MT1036.004←MT1036.005←MT1036.008←MT1036.009←MT1036.010←M →PT1036.011←MT1036.012←MT1037.001→PT1037.003→PT1055←MT1055.001←MT1055.002←MT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1056←MT1056.002←MT1056.004←MT1059.009→PT1068←MT1070←MT1070.003←MT1071←MT1071.001←MT1071.004←MT1072→PT1078→PT1078.001→MT1078.002→PT1078.003→MT1078.004→MT1090←MT1090.002←MT1090.003←MT1095←MT1098←P →PT1098.001←M →PT1098.002←P →PT1098.003←M →PT1098.004←P →PT1098.005→PT1098.006←M →PT1098.007←M →PT1102←MT1102.001←MT1102.002←MT1110→PT1110.001→MT1110.002→MT1110.003→MT1110.004→PT1111←MT1127←MT1127.001←MT1133→PT1134←MT1134.001←M →PT1134.002←MT1134.003←M →PT1134.004←MT1134.005←MT1136←P →PT1136.001←P →PT1136.002←M →PT1136.003←M →PT1137.001→PT1185←MT1199←M →PT1202←MT1204←MT1204.004←MT1207←MT1211←PT1212←PT1216←MT1216.001←MT1218←MT1218.003←MT1218.004←MT1218.005←MT1218.007←MT1218.008←M →PT1218.009←MT1218.010←MT1218.011←MT1218.012←MT1218.013←MT1219.003←MT1221←MT1222←MT1222.001←MT1222.002←MT1480.001←MT1484←M →PT1484.001←MT1484.002←M →PT1489←PT1496.004→PT1497←MT1528←M →PT1530←M →MT1531→PT1534→PT1535←MT1537←M →PT1538→PT1539→PT1542←MT1542.002←MT1542.003←MT1546.003→PT1546.012←PT1548←M →PT1548.002←MT1548.003←PT1548.005→PT1548.006←MT1550←M →PT1550.001←F →PT1550.002←F →PT1550.003←F →PT1550.004←FT1552.008→PT1553.001←MT1553.002←PT1553.003←MT1553.004←PT1553.006←MT1555.006→PT1556←M →PT1556.001←M →PT1556.002←FT1556.003←MT1556.004←MT1556.005←P →PT1556.006←MT1556.007←M →PT1556.008←M →PT1556.009←MT1557.001←MT1558←M →PT1558.001←M →PT1558.002←M →PT1558.003→PT1558.004→PT1563→PT1563.001←M →PT1563.002←M →PT1564←PT1564.001←MT1566.003←MT1568←MT1568.002←MT1571←MT1572←MT1574←MT1574.001←MT1574.013←MT1578←MT1578.001←MT1578.002←MT1578.003←M →PT1578.004←MT1578.005←MT1583.006←MT1583.007←MT1584.006←MT1585←MT1585.001←MT1585.002←MT1586→PT1586.001←M →PT1586.002←M →PT1586.003←M →PT1589.001←M →PT1598.003←MT1599←MT1599.001←PT1600←PT1601.001←PT1601.002←PT1606←M →PT1606.001←F →PT1606.002←MT1610←PT1620←MT1621←MT1647←PT1649←P →PT1650←MT1665←PT1666←MT1671←M →PT1683←MT1683.002←MT1684←M →PT1684.001→PT1684.002←MT1685←MT1685.001←MT1685.002←MT1685.003←MT1685.004←MT1685.005←MT1685.006←MT1686←FT1687←PT1688←MT1689←PT1690←M
Why these map — AI rationale (under review)
- T1003detects — A.5.16.f explicitly requires keeping records of significant events in identity management and authentication, which can surface credential-dumping activity after the fact when those logs are reviewed, but the control's core purpose and other clauses focus on provisioning, uniqueness, and lifecycle rather than mandating monitoring or anomaly detection for the technique itself.
- T1003.006detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous DCSync replication behavior by privileged accounts; this is genuine detection but only a minority slice of the technique (identity/account events, not the full replication API abuse or hash exfil itself).
- T1021prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, segregated non-human oversight, no duplicates) directly stop many classes of valid-account acquisition that T1021 relies on, but the control is silent on credential strength, theft vectors, and third-party federation risks that still enable the technique.
- T1021.001detects — A.5.16 clause (f) explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which surfaces anomalous or unauthorized RDP logons when they occur; this is genuine detection of the technique but only a minority slice because the control is scoped to identity lifecycle events rather than comprehensive behavioral, network, or host-based monitoring of RDP usage itself.
- T1021.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and limited shared accounts) directly constrain the pool of valid accounts an adversary can reliably use or acquire for RDP, but do not stop credential theft, service enablement, or use of already-compromised accounts.
- T1021.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability) directly constrain the creation and persistence of the valid administrator-level accounts that T1021.002 requires, but do not reach credential theft, pass-the-hash, or the SMB share configuration that still enable the technique with otherwise-valid identities.
- T1021.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, approval for shared/non-human) directly constrain the Valid Accounts prerequisite that T1021.003 explicitly depends on, but only for the account-management slice; the technique's core abuse of DCOM permissions/ACLs and insecure methods lives in a separate technical layer untouched by this control.
- T1021.004detects — A.5.16 clause f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which surfaces adversary use of valid accounts over SSH as detectable events (especially post-authentication actions), but this is only a minority slice of the technique's full surface (e.g., key-based auth setup, enabling SSH itself, or non-identity aspects).
- T1021.004prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) directly stop adversaries from obtaining or retaining the valid accounts needed to execute T1021.004; the bounded remainder is third-party-issued identities whose trust level is only required to be 'sufficiently treated' rather than guaranteed to block all SSH use.
- T1021.005detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous or unauthorized VNC sessions that rely on valid accounts; this is a genuine but minority slice of the technique (most of which lives in execution, lateral movement and the VNC implementation flaws themselves).
- T1021.005prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability) directly stop many valid-account abuses of VNC by ensuring stale, duplicated, or shared credentials cannot be used; the remainder is that the control is silent on credential strength, brute-force resistance, or VNC-specific configuration, which the technique can still exploit.
- T1021.006detects — A.5.16 f) explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which can surface anomalous or unauthorized use of valid accounts over WinRM as a detection signal, but this is only one narrow slice of the technique (identity lifecycle events) and does not broadly instrument WinRM execution, network activity, or process anomalies.
- T1021.006prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and limited shared accounts) directly constrain the supply and validity of the accounts that T1021.006 requires, but do not reach the adversary's use of already-compromised credentials or the WinRM service itself.
- T1021.007detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous or unauthorized use of federated/synchronized accounts against T1021.007; this is only a slice of the full technique surface (e.g. does not instrument all cloud CLI/API paths or token-based auth).
- T1021.007prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, single-person binding) directly constrain the creation and persistence of the synchronized/federated Valid Accounts that T1021.007 requires, but do not address authentication strength, token issuance, or third-party federation trust levels that the technique can still bypass.
- T1021.008prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) directly constrain the valid-account prerequisite for T1021.008, but leave residual paths such as approved shared identities, third-party credentials meeting the trust threshold, and post-compromise use of still-valid accounts.
- T1036.010detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces masquerading account-name creation/renaming events when they intersect monitored identity operations, but the control is silent on analysis, alerting or scope for non-identity events and does not mandate detection of the technique itself.
- T1036.010prevents — A.5.16's identity lifecycle rules (uniqueness per entity, timely disable/remove, segregated approval for non-human/shared accounts, and event logging) directly constrain the creation/renaming of masquerading accounts that duplicate or approximate legitimate ones, but do not reach all cases such as third-party identities or post-discovery modeling in every platform.
- T1037.001detects — A.5.16.f explicitly requires keeping records of significant events concerning the use and management of user identities, which can surface anomalous logon-script activity tied to identity lifecycle or usage, but this is only a narrow slice of the persistence technique itself (no broad monitoring or anomaly detection of script execution is required).
- T1037.003detects — A.5.16.f explicitly requires keeping records of significant events in identity management and authentication, which can surface anomalous use of network logon scripts tied to user identities (e.g. via audit of assignment or execution events), but this is limited to the identity slice and does not broadly instrument or detect the technique itself.
- T1059.009prevents — A.5.16's identity lifecycle rules (uniqueness, timely disable/remove, segregated non-human oversight, and proper assignment of access rights) constrain credential misuse that enables cloud API abuse, but do not stop an already-authorized identity from invoking the APIs.
- T1072prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and approval for shared identities) directly constrain the administrative or domain credentials required to access and abuse deployment tools, preventing the technique when those identities are absent or revoked; this is only a slice because the technique can also succeed via local credentials, direct third-party system access, or already-compromised admin sessions that bypass identity issuance controls.
- T1078prevents — Enforcing one-to-one identity-to-person mapping, timely disabling of unused accounts, and prohibiting duplicate identities directly reduces the pool of valid credentials an adversary can discover or abuse for unauthorized access.
- T1078detects — A.5.16 clause f explicitly requires keeping records of significant events in identity use and management, which surfaces anomalous or unauthorized use of valid accounts (including inactive ones) after the fact; this is genuine detection but only a minority slice of the full technique, which also includes credential compromise, permission overlap, and pivoting that live outside the identity-management event-logging boundary.
- T1078.001prevents — A.5.16's identity lifecycle processes (unique mapping, timely disable/remove of unneeded accounts, approval/oversight of shared or non-human identities, and change handling) directly stop most default-account abuse by ensuring preset or post-setup defaults are not left active/unchanged, though residual cases like factory defaults on unintegrated appliances or third-party credentials sit outside full coverage per the control's own scoping.
- T1078.002detects — A.5.16 clause f) explicitly requires keeping records of significant events in identity use and management, which surfaces anomalous or unauthorized domain account activity after the fact (e.g. via logs), but this is only one narrow slice of the full technique (acquisition via dumping/reuse, abuse for initial access/persistence/etc.) and does not mandate active monitoring or anomaly detection.
- T1078.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, no unauthorized sharing) directly stop most abuse paths for domain accounts by ensuring stale, duplicated, or poorly governed credentials cannot be obtained or used, though password reuse and dumping (T1003) can still succeed against live, valid ones.
- T1078.003detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities (including local accounts), which surfaces abuse after the fact as detection; this is only a minority slice of the full technique (initial access/persistence/escalation via credential abuse, dumping, or reuse) and does not address non-identity events or non-human accounts comprehensively.
- T1078.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight of non-human/shared accounts, and event logging) directly stop most abuse paths for local accounts by ensuring they cannot linger, be duplicated, or be used without accountability, though password-reuse and credential-dumping slices remain outside its direct reach.
- T1078.004prevents — A.5.16's identity lifecycle processes (unique mapping, timely disable/remove, segregated oversight of non-human/shared accounts, change handling) directly stop most T1078.004 abuse vectors that rely on stale, duplicated, over-privileged, or unmanaged cloud accounts; the bounded remainder is adversary compromise of still-valid, in-scope accounts via brute force/phishing that the control does not address.
- T1098detects — A.5.16.f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces account manipulation after the fact; this is limited to a logging slice rather than active detection tooling or coverage of all platforms and non-human identities.
- T1098prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, change handling) stop many manipulation vectors such as duplicate/shared accounts, stale credentials, or unapproved permission changes, but do not block all post-compromise manipulations once sufficient permissions already exist.
- T1098.001detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which would surface the addition of adversary-controlled credentials as a detectable event (especially for non-human identities under dedicated oversight), but this is only a logging/governance slice that does not guarantee actual detection tooling, alerting, or coverage of all cloud-specific addition methods such as API-driven SSH keys or temporary federation tokens.
- T1098.001prevents — A.5.16's identity lifecycle rules (single-entity mapping, timely disable/remove of unneeded identities, segregated approval/oversight for non-human identities, and change-handling) directly stop many of the credential-addition vectors that create duplicate or rogue identities on cloud principals, though they do not reach every API-driven addition that an already-privileged adversary can perform before the identity is reviewed or disabled.
- T1098.002detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities (including permission changes), which surfaces the adversary action of granting additional mailbox/delegate permissions after it occurs.
- T1098.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human/shared identities, and change-handling) directly stop many permission-granting actions that create duplicate or unauthorized access delegations, but do not reach all cases such as adversary-controlled accounts or post-compromise folder-permission assignments that stay within an already-authenticated identity.
- T1098.003detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities, which would surface the addition of cloud roles/permissions as a detectable event, but the control is silent on active monitoring, alerting, or analysis of those records and does not reach external-account role additions.
- T1098.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human, dedicated oversight of shared identities) directly constrain the creation or persistence of the extra privileged roles the technique adds, but stop short of stopping an already-compromised account that already holds the permission to call AttachUserPolicy/CreatePolicyVersion or to federate an external identity.
- T1098.004prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) directly stop many unauthorized SSH key additions that abuse or create rogue identities, but leave open adversary modifications via direct file edits, cloud APIs, or config changes that do not alter the identity record itself.
- T1098.005detects — A.5.16.f explicitly requires keeping records of all significant events concerning the use and management of user identities (including device registration to accounts), which surfaces the technique after it occurs in the identity-management domain, but this is only a logging slice with no mandated analysis, alerting or monitoring depth.
- T1098.005prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human, oversight of shared) directly stop adversary-controlled or duplicate device identities from being validly registered and persisting in MFA/device systems, but do not reach all enrollment paths (e.g. post-compromise self-enrollment using stolen creds or inactive accounts)
- T1098.006detects — A.5.16 clause (f) explicitly requires keeping records of all significant events concerning the use and management of user identities (including non-human/service accounts), which surfaces the account-permission modification event described in T1098.006; this is only a slice of the full technique because the control is silent on analysis, alerting, or real-time detection of the binding/role changes themselves.
- T1098.006prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human identities, and change-handling) directly stop many of the account/role-binding modifications that constitute T1098.006, but leave the post-compromise modification of already-valid accounts (and third-party identity trust gaps) unaddressed.
- T1098.007detects — A.5.16.f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces additions of groups to accounts as an identity-management event; this is genuine detection but only a slice of the full technique (no requirement for real-time alerting, anomaly-based detection outside identity events, or coverage of non-identity artifacts).
- T1110detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces brute-force attempts against accounts as detectable events; this is limited to a minority slice because the control is scoped to identity/account events rather than mandating broad monitoring, detection logic, or coverage of offline hashing or non-account vectors.
- T1110prevents — A.5.16's identity lifecycle rules (unique per-entity mapping, timely disable/remove, segregated non-human oversight, and limited shared accounts) directly block the credential-guessing surface of T1110 by shrinking the pool of live, guessable accounts and enforcing accountability that makes brute-force detectable and attributable; the remainder is that it does not mandate password strength, lockouts, or MFA (those live in 5.17).
- T1110.001detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces password-guessing attempts as detectable events; this is limited to a governance/audit-logging slice rather than mandating instrumentation depth or real-time detection across all listed services and platforms.
- T1110.001prevents — A.5.16's identity lifecycle rules (unique per-entity mapping, timely disable/remove, segregated non-human oversight, and accountability linkage) directly stop guessing from succeeding against valid accounts by ensuring credentials tie to live, single, known entities and are revoked promptly, matching the A.8.5 anchor's 'prevents' mostly grading on the same technique.
- T1110.002prevents — A.5.16's identity lifecycle (unique per-entity mapping, timely disable/remove on departure/role-change, approval for shared/non-human, event logging) directly stops many cracked credentials from being usable by ensuring stale, duplicate or orphaned accounts cannot authenticate, though it does not stop the offline cracking act itself or reach password-strength aspects.
- T1110.003detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces password-spraying attempts as detectable events; this is only a slice of the full technique (throttled/low-visibility LDAP/Kerberos paths, federated/SSO targets, and non-event-based spraying remain outside the identity-management records scope).
- T1110.003prevents — A.5.16's identity lifecycle rules (unique per-entity mapping, timely disable/remove, segregated non-human oversight, and change/re-verification processes) directly stop most password-spraying success by ensuring few or no valid low-entropy accounts exist to spray against; the bounded remainder is third-party federated identities whose trust level is only required (not enforced) by the clause.
- T1110.004detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces credential-stuffing attempts as anomalous login events; this is only a slice of the full technique (e.g. does not address the breach-dump sourcing or non-login aspects), matching the partial scope precedent in A.8.16 vs T1055.
- T1110.004prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, change handling) close the overlap window that credential stuffing exploits for many accounts, but do not stop reuse of valid third-party credentials, shared identities permitted for business reasons, or the initial breach that supplies the credential pairs.
- T1133prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, approved shared identities, and event logging) directly constrain the Valid Accounts prerequisite for most T1133 vectors (VPNs, Citrix, RDP, etc.), but leave the unauthenticated-exposed-service slice (Docker/K8s APIs, Tor hidden services) and post-compromise credential-pharming untouched.
- T1134.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, accountability) constrain token misuse vectors that rely on stale, shared, duplicate or non-human identities, but do not stop an already-authenticated process/thread from calling DuplicateToken/ImpersonateLoggedOnUser APIs against a live valid token.
- T1134.003detects — A.5.16.f explicitly requires keeping records of significant events in identity management and authentication, which can surface token creation/impersonation anomalies when monitored, but this is only a minority slice of the technique (most executions occur without touching identity lifecycle events).
- T1134.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability linkage) constrain creation and use of impersonation tokens by enforcing that only approved, single-entity identities exist and can be activated, but do not reach the Windows API-level technique of forging a new logon token via LogonUser/SetThreadToken.
- T1136detects — A.5.16 clause (f) explicitly requires keeping records of significant events in the use and management of user identities, which surfaces creation of (especially non-approved or duplicate) accounts as detectable events; this is a genuine but minority slice of the broad technique that also covers stealthy/low-privilege service accounts outside identity-management oversight.
- T1136prevents — A.5.16's identity lifecycle processes (unique mapping, timely disable/remove of unneeded accounts, segregated approval/oversight, and change handling) directly stop many unauthorized account creations that would otherwise persist, but do not reach all creation vectors (e.g., initial compromise with sufficient privileges, third-party identity issuance, or cloud service-specific accounts).
- T1136.001detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces creation of a local account as an auditable event; this is genuine detection but only a slice of the full technique surface (e.g. silent creation via exploited management consoles or non-human service accounts may evade the logging scope).
- T1136.001prevents — A.5.16's identity lifecycle processes (unique mapping, approval/oversight of non-human/shared accounts, timely disable/remove when no longer needed) directly constrain or block many creation paths for unauthorized local accounts used in persistence, but do not reach all adversary creation vectors (e.g. post-exploitation via vulnerable management consoles or direct CLI abuse with existing privileges).
- T1136.002detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces creation of a domain account as an auditable event; this is only a slice of the full technique (no requirement for real-time alerting, analysis, or coverage of non-human/service accounts beyond oversight).
- T1136.002prevents — A.5.16's identity lifecycle processes (unique mapping, approval/oversight of non-human/shared accounts, timely disable/remove when no longer needed) constrain or block many illegitimate domain account creations for persistence, but do not stop an already-privileged adversary from issuing the creation command before oversight or removal can act.
- T1136.003detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities (including creation), which surfaces the adversary action of creating a cloud account; this is genuine detection but only a minority slice of the full technique (non-human/service accounts, stealthy low-privilege accounts, and post-creation manipulation live outside the clause's explicit identity-management focus).
- T1136.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human/service identities, and change-handling) directly constrain the creation and persistence of rogue cloud accounts or service principals, but only for identities the organization itself manages or approves; adversary-created shadow accounts outside that process remain possible.
- T1137.001prevents — A.5.16's identity lifecycle (unique mapping, timely disable/remove, approval/oversight of non-human/shared identities) can prevent some abuse vectors that rely on rogue or orphaned identities to plant/modify templates or macros, but leaves the dominant technique (modifying templates under an already-authorized user identity) untouched.
- T1199prevents — A.5.16's processes for segregated approval/oversight of non-human identities, timely disablement, single-entity mapping, and requiring sufficient trust/risk treatment for third-party identities directly constrain the creation or persistence of the exploitable trusted relationships and accounts that T1199 abuses, but do not stop all such third-party access grants or their compromise.
- T1218.008detects — A.5.16 clause f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous or unauthorized use of signed binaries like odbcconf.exe for proxy execution when tied to identity context; this is a genuine but minority slice of the technique (most detections live in process monitoring or EDR, not identity lifecycle).
- T1484detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities (and authentication information), which would surface modifications to domain/tenant identity policy, identity federation, or related configuration changes; this is only a slice of the technique (e.g. does not address GPO abuse for scheduled tasks or rogue DC changes outside the identity-management event set).
- T1484.002detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities (and authentication information), which surfaces malicious trust modifications that alter identity federation, providers, or related auth material; this is a genuine but bounded slice because the control is silent on automated analysis, alerting, or real-time detection of the events it logs.
- T1484.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval for non-human identities, and third-party trust vetting) constrain some trust-modification vectors that rely on rogue identities or unvetted federated providers, but do not stop an already-privileged adversary from directly altering domain/tenant trust objects or federation settings.
- T1496.004prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, segregated non-human oversight, and change handling) stop many hijack paths that rely on stale, shared, duplicate, or poorly deprovisioned identities, but leave open adversary use of already-compromised live identities, third-party federated credentials, or post-enablement abuse of SaaS quotas.
- T1528prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, change handling) directly stop many token-theft vectors that rely on stale, duplicated, shared, or unmanaged identities/tokens, but leave social-engineering OAuth flows, post-compromise token extraction from running containers/CI pipelines, and refresh-token abuse untouched.
- T1530prevents — A.5.16's identity lifecycle processes (unique mapping, timely disable/remove, segregated non-human oversight, approved shared IDs, and IAM-linked access rights) directly close the improper IAM configurations and leaked-credential vectors that enable unauthenticated or overly-broad cloud storage access, leaving only the bounded remainder of purely misconfigured object ACLs or bucket policies that do not involve identity at all.
- T1531detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities, which surfaces adversary account manipulation or removal actions after they occur.
- T1534detects — A.5.16 point f explicitly requires keeping records of significant events in identity use and management, which can surface anomalous internal account activity or impersonation patterns that are part of T1534, but this is only a logging slice and does not mandate active detection, alerting, or coverage of the phishing delivery vectors themselves.
- T1537detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities (including non-human ones and third-party identities), which would surface anomalous transfers to adversary-controlled accounts that abuse identity or access rights, but this is only a slice of the technique's surface (e.g. it does not address the backup/sync mechanisms or internal API blending themselves).
- T1538prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove on departure/role change, approval for shared/non-human, event logging) stop many stolen-credential scenarios at the identity-provisioning or revocation stage, but leave the post-compromise use of already-valid credentials against a dashboard untouched.
- T1539detects — A.5.16 point f explicitly requires keeping records of significant events concerning the use and management of user identities and authentication information, which would surface anomalous session-cookie usage or theft as a detectable event; this is only a slice of the full technique surface (e.g. local malware theft, JS injection, or proxy-based theft may not all trigger identity-management events).
- T1539prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, oversight of non-human identities, event logging) constrain session-cookie issuance and validity windows for many enterprise identities, but do not stop local theft, JS injection, malicious-proxy collection, or post-theft use of an already-valid cookie.
- T1546.003detects — A.5.16 f) explicitly requires keeping records of significant events in identity management and authentication, which can surface anomalous or unauthorized WMI subscriptions tied to identity changes or access (e.g. new logins or privilege elevations), but this is limited to the identity slice of the technique and does not broadly instrument WMI event filters, MOF compilation, or runtime execution.
- T1548prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated approval, accountability) directly stop many elevation paths that rely on duplicate/shared/stale identities or unvetted non-human accounts, but leave the bulk of native mechanism-abuse techniques (UAC bypass, sudo flaws, token manipulation, etc.) untouched.
- T1548.005detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces (i.e. detects) abuse of temporary elevated access via just-in-time, impersonation or role-passing mechanisms; this is only a slice of the full technique because the control is silent on real-time monitoring, anomaly detection, or coverage of non-identity events.
- T1548.005prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, accountability linkage) directly constrain the misconfigurations that enable temporary elevation paths such as unchecked JIT requests, impersonation grants, and PassRole abuse, but only address the identity/account slice; they leave the distinct permission-configuration and role-assignment errors untouched.
- T1550prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) stop many alternate-auth-material issuance and reuse paths that rely on duplicate, stale, or improperly approved identities, but do not address theft or replay of already-issued material such as stolen Kerberos tickets or cached tokens.
- T1550.001detects — A.5.16 clause (f) explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which can surface anomalous token usage or issuance after the fact; this is a genuine but minority slice of the technique (most token abuse occurs post-compromise without triggering identity-lifecycle events).
- T1550.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, accountability linkage) constrain some token issuance and persistence vectors but leave the dominant post-compromise use of already-stolen tokens and refresh-token abuse untouched.
- T1550.002detects — A.5.16 f) explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which can surface PtH activity when those events are reviewed or monitored; this is only a slice of the full technique (e.g. does not address hash capture, overpass-the-hash Kerberos paths, or non-identity events).
- T1550.003detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which would surface PtT usage of stolen or forged Kerberos tickets as anomalous identity/auth events; this is genuine detection coverage but only a minority slice because the control is primarily about identity lifecycle governance rather than real-time monitoring or broad anomaly detection of credential abuse techniques.
- T1550.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, accountability linkage) prevent many PtT vectors that rely on stale, shared, duplicate, or improperly deprovisioned identities/tickets, but leave the dominant post-compromise ticket-theft and forgery paths (from OS Credential Dumping or KRBTGT compromise) untouched.
- T1552.008detects — A.5.16 point f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which surfaces credential-sharing events in chat services when those events intersect monitored identity/authentication activity; this is a genuine but minority slice of the technique (most credential extraction from chats is not tied to identity events).
- T1555.006detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which would surface API-driven secret retrievals by non-human or privileged identities in cloud secret managers as detectable events.
- T1556detects — A.5.16 clause f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous or malicious modifications to auth processes (the core of T1556) when those events are reviewed or monitored.
- T1556prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and third-party trust) stop many T1556 vectors that rely on duplicate, orphaned, shared or weakly-vetted identities, but do not constrain direct modification of the authentication mechanisms (LSASS, PAM, plugins) themselves.
- T1556.001detects — A.5.16.f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which can surface anomalous authentication events (including those from a domain controller patch) after the fact; this is only a slice of the technique's full execution chain (e.g., the initial LSASS patching itself is outside identity-management scope).
- T1556.005detects — A.5.16 clause (f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which would surface the adversary's configuration change that enables reversible encryption (a detectable management event on AD accounts or FGPP).
- T1556.007detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces anomalous or backdoored hybrid identity behavior once it occurs, but only for events the organization has instrumented and reviewed.
- T1556.007prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight of non-human identities, and accountability) constrain hybrid identity backdooring vectors that rely on duplicate, orphaned, or improperly approved identities, but do not address the core technique of patching/modifying the on-premises/cloud authentication processes themselves.
- T1556.008detects — A.5.16 clause (f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which would surface anomalous or malicious network provider/credential-manager registrations during logon events; this is a genuine but minority slice of the full technique (which also includes stealthy Registry-based installation and DLL loading outside monitored identity events).
- T1558detects — A.5.16.f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which can surface Kerberos ticket theft or forgery after the fact as anomalous identity/auth events.
- T1558.001detects — A.5.16 clause f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which surfaces golden ticket forgery and use after the fact via logs (e.g. anomalous TGT/TGS patterns), but this is only a minority slice of the technique's full kill-chain footprint (KRBTGT hash theft via T1003, domain-controller access, and offline forgery).
- T1558.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) constrain KRBTGT and related account identities enough to block some golden ticket paths, but do not reach the dominant root cause of KRBTGT hash theft via privileged access and credential dumping.
- T1558.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and change handling) directly stop many service-account identities from existing in a forgeable state or persisting after compromise, but do not reach the core technique of forging a TGS ticket from an already-compromised hash obtained via dumping or Kerberoasting.
- T1558.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight of non-human/service accounts, and accountability) directly constrain the creation and persistence of the weak service accounts that Kerberoasting relies on, but do not reach the RC4 encryption, TGT/TGS request mechanics, or network sniffing that enable the technique.
- T1558.004prevents — A.5.16's identity lifecycle (unique mapping, timely disable/remove, approval/oversight of non-human/shared accounts, and event logging) directly stops creation or persistence of the vulnerable accounts that enable AS-REP roasting, but leaves residual cases such as third-party identities, legacy configurations, or accounts disabled after initial enumeration.
- T1563detects — A.5.16 f) explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which can surface hijacking of preexisting sessions as anomalous identity or session events; this is only a slice of the full technique (e.g., does not address non-identity observables or post-hijack actions).
- T1563.001detects — A.5.16.f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which would surface anomalous hijacking of an active SSH session or its agent/socket as a detectable identity/auth event; this is only a slice of the full technique surface (e.g., root-level agent compromise or non-identity aspects remain outside this control's view).
- T1563.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability) constrain SSH key/agent identity reuse and stale sessions that enable hijacking, but do not reach agent-socket protections, root-level triviality, or runtime session isolation.
- T1563.002detects — A.5.16 point f explicitly requires keeping records of significant events in the use and management of user identities and authentication information, which would surface anomalous RDP session hijacking events (e.g. unexpected session takeovers or tscon.exe usage tied to identity misuse) within the monitored identity domain, but this is only a slice of the full technique as the control does not mandate broader behavioral or host-based detection outside identity events.
- T1563.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and event logging) constrain some hijack vectors that rely on stale, shared, or duplicate sessions, but do not stop the core technique of using tscon.exe with System privileges on an active legitimate session.
- T1578.003detects — A.5.16 clause (f) explicitly requires keeping records of significant events in the use and management of identities, which surfaces the deletion (or creation-then-deletion) of a cloud instance tied to an identity, providing detection knowledge without stopping or undoing the technique.
- T1586prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, segregated oversight, change handling, and third-party trust vetting) stop many compromise vectors such as stale/shared accounts, duplicate personas, and unvetted external credentials, but leave open purchase of valid credentials, insider sales, and post-compromise persona development.
- T1586.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, third-party trust/risk treatment, approval/oversight of shared/non-human identities) directly constrain the creation and ongoing viability of the compromised social-media personas that T1586.001 relies on, but do not stop upstream credential theft methods (phishing, purchase, brute-force) or reconnaissance that enable the compromise.
- T1586.002prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, third-party trust vetting) directly block several compromise vectors such as shared/duplicate accounts, orphaned credentials, and low-trust external identities, but leave untouched brute-force, phishing-for-credentials, purchase, or insider-sale paths that the technique explicitly lists.
- T1586.003prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated oversight, restricted shared identities) directly stop many account-compromise vectors that rely on stale, duplicated, shared, or poorly governed cloud credentials, but leave untouched external acquisition methods such as purchasing credentials, phishing-for-information, or exploiting trusted relationships outside the organization's identity domain.
- T1589.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, limited shared accounts) directly shrink the pool of valid credentials an adversary can usefully gather or reuse, but do nothing against external elicitation, breach dumps, dark-web purchases, or third-party credential harvesting that the technique explicitly names.
- T1606prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability) constrain many legitimate pathways that adversaries abuse to obtain or maintain the secrets needed to forge web credentials, but do not reach the core generation step itself when the adversary already possesses a valid secret, key, or privileged API access.
- T1606.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, and accountability) directly stop forged-cookie issuance and use when the cookie impersonates a managed identity, but leave the remainder of secret-material theft, weak cookie signing algorithms, and third-party identity trust gaps untouched.
- T1649detects — A.5.16 point f explicitly requires keeping records of all significant events concerning the use and management of user identities and authentication information, which surfaces certificate theft or forgery events when they involve identity/authentication material, but this is only a minority slice of the technique (most certificate theft/forge paths and golden-certificate issuance sit outside routine identity-event logging).
- T1649prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, segregated non-human oversight, no duplicates) directly stop many certificate-for-identity abuses such as forging for impersonation or persisting via stolen certs tied to invalid entities, but leave the core certificate theft, CA key compromise, enrollment-rights, and cryptographic forgery vectors untouched.
- T1671prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove on role change or departure, segregated non-human oversight, and event logging) directly constrain adversary creation/co-opting of service principals or OAuth apps tied to accounts, but leave open the consent-granting path from a still-valid high-privileged account and do not reach the full technique surface (e.g. persisting post-account-disable via tokens).
- T1684prevents — A.5.16's identity lifecycle rules (unique binding, timely disable/remove, segregated approval, oversight of non-human identities, and event logging) constrain the success and blast radius of social-engineering-induced actions such as password resets, MFA changes, or unauthorized approvals, but do not stop the adversary from influencing the initial human action itself.
- T1684.001prevents — A.5.16's identity lifecycle rules (unique mapping, timely disable/remove, segregated non-human oversight, third-party trust vetting) prevent some impersonation vectors that rely on duplicate, orphaned, shared or weakly-vetted identities, but do not stop reconnaissance, domain acquisition, or social-engineering content that forges trusted appearance without using a real identity.
Prevented OWASP Web Top 10 (2025) risks (7)
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)
- A07mitigates — A.5.16's identity lifecycle (unique mapping, timely disable/remove, oversight of non-human/shared IDs, event logging) bounds the blast radius and reduces hijacking/credential-stuffing surface of realized auth failures without stopping the verification or session flaws themselves
- A07prevents — A.5.16's core processes for unique single-entity identities, timely disable/remove, segregated non-human oversight, and change handling directly block the dominant authentication-failure root causes (weak identity binding, orphaned accounts, duplicate IDs, hijackable shared creds) that enable the listed attacks; the remainder is implementation bugs in the downstream auth mechanisms themselves (e.g. flawed reset or session logic) that live in A.5.17.
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.