A.8.2 Technological
Privileged access rights
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (11)
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 require formal authorization, periodic review, and timely revocation or expiry of privileged accounts to keep access aligned with current responsibilities.
- AC-6mostlycovers — Both controls focus on restricting elevated privileges to the minimum necessary for role-based duties and enforcing separate identities for privileged versus ordinary tasks.
- AC-3partialaligns with — The ISO control’s emphasis on an authorization process and enforcement of privileged rights directly supports the broader access-enforcement objective in AC-3.
- AU-2partialaligns with — Mandating audit logging of all privileged access activities satisfies the event-logging requirement for security-relevant actions.
- IA-2partialaligns with — Requiring stronger or step-up authentication for privileged sessions aligns with the identification and authentication controls for organizational users.
Aligned NIST CSF 2.0 outcomes (11)
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-01mostlyaligns with — Managing privileged identities, credentials, and their lifecycle (allocation, expiry, temporary use, and non-sharing) fulfills the CSF outcome of managing identities and credentials for authorized users and services.
- PR.AA-05mostlyaligns with — The ISO control's authorization process, role-based allocation, periodic reviews, and separation of privileged versus normal identities directly support defining, managing, enforcing, and reviewing access permissions and entitlements.
- GV.RR-02partialaligns with — Establishing who can approve privileged rights, maintaining authorization records, and reviewing role qualifications help define and communicate roles, responsibilities, and authorities for access-related risk management.
- PR.AA-03partialaligns with — Elevated authentication requirements, step-up authentication, and break-glass procedures strengthen the authentication of users and services when privileged rights are exercised.
- PR.PS-04partialaligns with — Mandating audit logging of all privileged access activities contributes to generating log records that enable continuous monitoring and accountability.
Related OWASP ASVS 5.0 requirements (13)
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)
- V8.2.1mostlyaligns with — Both require that privileged or administrative functions are only reachable by identities that have been explicitly granted the necessary permissions.
- V8.3.1mostlyaligns with — The ISO control’s insistence on an authorization process and trusted service-layer enforcement mirrors the ASVS requirement that authorization decisions must be made at a trusted backend rather than by client-side controls.
- V16.3.2partialaligns with — Logging every use of privileged access rights satisfies the ASVS requirement to record all authorization decisions, including those granting elevated privileges.
- V6.3.2partialaligns with — The explicit prohibition of shared generic administration accounts (root, admin) directly supports the ASVS rule that default privileged accounts must be disabled or removed.
- V6.3.3partialaligns with — Requiring stronger or step-up authentication for privileged access rights aligns with the ASVS mandate that privileged or high-impact actions must be protected by multi-factor or equivalent controls.
- V7.5.3partialaligns with — The ISO guidance that privileged actions should trigger re-authentication or step-up authentication corresponds to the ASVS requirement for additional authentication before performing highly sensitive operations.
Related weaknesses / CWE (115)
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-1259mostlyprevents — Privileged access rights help ensure only authorized processes can assign or modify tokens.
- CWE-1334mostlyprevents — Restricting privileged access rights limits the ability of insiders or compromised accounts to tamper with redundancy mechanisms.
- CWE-15mostlyprevents — Privileged access rights reduce the number of users who can alter configuration.
- CWE-250mostlyprevents — Mandating separate non-privileged identities for routine work and restricting privileged accounts to administrative tasks reduces the chance that everyday operations run with unnecessary elevated rights.
- CWE-266mostlyprevents — Privileged-access-rights control explicitly requires least-privilege assignment and ongoing validation, directly mitigating CWE-266.
- CWE-268mostlyprevents — Restricting privileged access rights directly mitigates the risk of privilege chaining.
- CWE-269mostlyprevents — Enforcing minimum-necessary privileges, temporary grants, and separation of administrative versus normal identities prevents the over-assignment of rights that CWE-269 describes.
- CWE-270mostlyprevents — Privileged-access-rights control directly addresses improper privilege elevation during context switches.
- CWE-274mostlyprevents — Privileged-access-rights control directly limits the situations in which insufficient privileges can occur.
- CWE-284mostlyprevents — Requiring explicit authorization, role-based allocation, and periodic review of privileged rights directly stops the assignment of excessive or unauthorized administrative capabilities that CWE-284 captures.
- CWE-286mostlyprevents — Privileged access rights assume correct user accounts exist; the control does not manage user creation or removal.
- CWE-419mostlyprevents — Privileged access rights directly restrict who can use the primary administrative channel.
- CWE-424mostlyprevents — Privileged access rights must be enforced on every possible route to privileged functions.
- CWE-612mostlyprevents — Privileged access rights may be used to enforce index restrictions but are not the primary control.
- CWE-732mostlyprevents — Documented authorization, expiry rules, and audit logging of privileged accounts make it harder for critical resources to retain overly permissive or stale permission assignments.
- CWE-842mostlyprevents — Privileged access rights depend on correct groups, yet the control focuses on elevated privileges rather than group assignment accuracy.
- CWE-1191partialmitigates — Privileged-access rules may extend to hardware debug interfaces, yet the control is not hardware-specific.
- CWE-1220partialprevents — Specifies management of privileged access rights, where overly broad privileges are a common manifestation of the weakness.
- CWE-1234partialmitigates — Privileged access rights can restrict debug-mode overrides but do not specifically address hardware lock bypass.
- CWE-1244partialmitigates — Privileged access rights management can limit debug-level access but does not specifically address hardware debug interface misconfiguration.
- CWE-1256partialmitigates — Privileged access rights limit who can invoke hardware-control interfaces, reducing the attack surface for unauthorized register/memory manipulation.
- CWE-1262partialprevents — Privileged access rights directly restrict who can read/write hardware registers.
- CWE-1268partialprevents — Specifies management of privileged access rights, mitigating discrepancies between control-plane and data-plane privileges.
- CWE-1274partialprevents — Privileged access rights can limit who or what can write to volatile memory used for boot code.
- CWE-214partialmitigates — Privileged access rights reduce exposure of sensitive command-line arguments to unauthorized observers.
- CWE-267partialmitigates — Privileged access rights control can restrict unsafe privileges, yet does not ensure the privilege definition itself is safe.
- CWE-272partialmitigates — Privileged access rights explicitly require least-privilege assignment and timely revocation after elevated operations.
- CWE-283partialprevents — Privileged access rights assignment should verify ownership to prevent unauthorized elevation on critical resources.
- CWE-288partialprevents — Privileged access rights control reduces risk of bypass through elevated or alternate paths.
- CWE-290partialprevents — Privileged access rights reduce attack surface but do not prevent spoofing of authentication.
- CWE-291partialprevents — Privileged-access rules require authenticated users rather than implicit IP trust.
- CWE-408partialprevents — Privileged access rights limit who can perform costly actions but do not enforce authentication order.
- CWE-412partialmitigates — Privileged access rights limit who can create or manipulate locks, reducing external influence.
- CWE-422partialmitigates — Privileged access rights reduce the attack surface by limiting processes that run elevated and can be targeted via shatter attacks.
- CWE-507partialmitigates — Privileged access rights reduce the ability to install or run Trojan Horse code but do not eliminate it.
- CWE-520partialmitigates — Restricting privileged access rights directly limits the ability to grant impersonation privileges that escalate .NET process rights.
- CWE-556partialmitigates — Privileged access rights policy limits the use of impersonation to only what is strictly required.
- CWE-638partialprevents — Privileged access rights management reduces risk but does not mandate per-access mediation.
- CWE-639partialmitigates — Privileged access rights control restricts what data each user may access, mitigating direct object reference attacks.
- CWE-642partialprevents — Restricting privileged access rights reduces the chance that state data can be tampered with by unauthorized users.
- CWE-653partialmitigates — Privileged access rights require strict isolation from ordinary user contexts.
- CWE-708partialprevents — Privileged-access rules often include ownership checks, yet the control focuses on elevated rights rather than ownership correctness.
- CWE-749partialprevents — Privileged access rights limit who can invoke dangerous methods, but do not address whether the method itself should exist.
- CWE-782partialprevents — Privileged access rights directly restrict who may invoke sensitive IOCTLs.
- CWE-1189nonenone — Privileged access rights can reduce unauthorized software access to SoC resources but do not enforce hardware isolation.
- CWE-1231nonemitigates — Privileged access rights can limit who can change lock bits, but does not enforce hardware-level immutability.
- CWE-1280nonenone — Limits privileged rights but does not guarantee the check precedes access.
- CWE-1391nonenone — Restricts privileged accounts but does not explicitly address default or hard-coded credentials for those accounts.
- CWE-1393nonenone — Privileged accounts must not retain factory passwords, reducing risk of default-credential abuse.
- CWE-271nonemitigates — Privileged access rights explicitly require least-privilege assignment and timely revocation, directly mitigating failure to drop privileges.
- CWE-273nonenone — Privileged access rights policy requires verification that privilege changes succeed, directly addressing failed privilege drops.
- CWE-277nonenone — Privileged access rights management can limit inheritance of excessive permissions but does not directly address insecure default permission inheritance.
- CWE-279nonemitigates — Privileged access rights management directly constrains the permissions a process may assign at runtime.
- CWE-280nonenone — Requires explicit management of privileged access rights, reducing the chance of missing privilege checks.
- CWE-281nonenone — Privileged-access management includes rules for maintaining correct permissions on copied or restored data.
- CWE-282nonemitigates — Privileged access rights management requires accurate ownership to prevent unauthorized privilege escalation.
- CWE-308nonenone — Privileged access rights can be conditioned on MFA, but the control focuses on privilege scope rather than factor count.
- CWE-309nonenone — Privileged access rights presuppose secure authentication but do not specify the mechanism.
- CWE-425nonenone — Privileged access rights control enforces least-privilege checks on restricted endpoints.
- CWE-441nonenone — Privileged-access controls limit the rights the product may exercise on behalf of upstream callers, mitigating confused-deputy abuse.
- CWE-566nonenone — Restricting privileged database access limits the impact if an authorization bypass occurs, but does not prevent the flaw itself.
- CWE-648nonemitigates — Privileged access rights directly govern the correct use of privileged APIs and reduce misuse.
- CWE-654nonenone — Privileged access rights can stipulate MFA, but the control focuses on privilege scope rather than factor count.
- CWE-671nonenone — Privileged access rights control ensures administrators can configure and restrict elevated security functions.
- CWE-673nonemitigates — Restricting privileged access reduces the ability of external actors to change sphere definitions.
- CWE-778nonenone — Requiring comprehensive logging of all privileged access creates the audit trail needed to detect misuse that would otherwise go unrecorded.
Mitigated MITRE ATT&CK techniques (8)
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).
Why these map — AI rationale (under review)
- T1078.002fullprevents — Domain accounts granted privileged rights must be individually authorized, time-limited, and reviewed, reducing the window and scope for domain-level abuse.
- T1078mostlyprevents — Requiring explicit authorization, time-bound allocation, separate privileged identities, and regular reviews sharply limits the ability of an adversary to abuse valid accounts with elevated rights.
- T1098mostlyprevents — Any manipulation or addition of privileged rights must pass the same authorization and logging controls, limiting an adversary’s ability to persist via account changes.
- T1136mostlyprevents — Privileged account creation is gated by an authorization process and recorded, preventing attackers from creating stealthy new privileged accounts without detection.
- T1548mostlyprevents — Stronger authentication, step-up re-authentication, and separate privileged identities raise the bar for bypassing or abusing elevation mechanisms.
- T1556mostlyprevents — Elevated authentication requirements and step-up re-authentication for privileged rights hinder attempts to weaken or bypass authentication processes.
- T1078.003partialprevents — Local privileged accounts are issued only after authorization, with expiry and non-sharing rules, making long-term or shared local-admin compromise harder.
- T1548.002nonemitigates — Requiring explicit approval and higher authentication for privileged rights makes it harder for malware or users to silently bypass UAC or similar elevation prompts.
Prevented OWASP Web Top 10 (2025) risks (3)
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)
- A01mostlyprevents — Strict authorization, time-boxing, and separation of privileged identities directly stop unauthorized elevation or lateral movement that would otherwise bypass access-control checks.
- A07partialmitigates — Requiring stronger authentication, step-up re-authentication, and unique privileged accounts reduces the chance that stolen or weak credentials can be used for administrative compromise.
- A09nonemitigates — Mandatory logging of every privileged session supplies the audit trail needed to detect and investigate unauthorized administrative actions after the fact.
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.