Essential Eight RA-ML1.1 Validating privileged access requests upon initial request

This control partially meets A.5.15.

E8-RA-ML1.1 requires organisations to validate privileged access requests upon initial request. Annex A 5.15 requires establishing and implementing access control policies and procedures based on business and security requirements. E8-RA-ML1.1 is a specific procedural requirement that would typically sit under and be driven by the broader policy framework in Annex A 5.15.

This control partially meets A.5.18.

E8-RA-ML1.1 requires organisations to validate privileged access requests when first requested, prior to provisioning. Annex A 5.18 addresses the broader lifecycle of access rights provisioning, review, modification and removal in line with access control rules. E8-RA-ML1.1 maps to the initial provisioning/authorisation component, while Annex A 5.18 extends beyond initial request validation into ongoing management.

This control partially meets A.8.2.

E8-RA-ML1.1 requires organisations to validate privileged access requests when they are first requested. Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation and use, covering broader privileged access governance. E8-RA-ML1.1 is one specific control activity within that broader management lifecycle (initial validation/provisioning decision).

This control is equivalent to ISM-1507.

ISM-1507 requires that requests for privileged access to systems and resources are validated at the time they are first requested. E8-RA-ML1.1 states the same requirement for systems, applications and data repositories, focusing on initial validation of privileged access requests before approval. The scope and intent align closely, with only minor wording differences in the assets referenced.

This control partially overlaps ISM-0446.

ISM-0446 requires that foreign nationals are not granted privileged access to AUSTEO/REL systems. E8-RA-ML1.1 requires validation of requests for privileged access when first requested, which is a practical control point to check eligibility (including whether the requester is a foreign national) before granting access. E8-RA-ML1.1 is process-focused and applies generally, while ISM-0446 is a specific prohibition for a defined cohort and data sensitivity scope.

This control partially overlaps ISM-1508.

E8-RA-ML1.1 requires organisations to validate privileged access requests upon initial request. This overlaps with ISM-1508 because initial validation should confirm the privileged access being requested is limited to what is required for users and services to perform their duties. ISM-1508 is a broader least-privilege requirement across privileged access generally, while E8-RA-ML1.1 is specifically about validating the request at the start of the access lifecycle.

This control partially overlaps ISM-1647.

E8-RA-ML1.1 requires organisations to validate privileged access requests when first requested to ensure only legitimate admin access is granted. ISM-1647 relates by requiring privileged access to be disabled after 12 months unless it is revalidated, which is a form of periodic re-approval. ISM-1647 addresses ongoing entitlement recertification and expiry, while E8-RA-ML1.1 is focused on the upfront approval step.

This control partially overlaps ISM-1883.

E8-RA-ML1.1 requires organisations to validate privileged access requests at the point they are first raised. This relates to ISM-1883 because validating a request should include confirming the requested privileged access to online services is explicitly authorised and limited to what is necessary for service duties. ISM-1883 focuses on ongoing least-privilege scoping of privileged accounts for services, whereas E8-RA-ML1.1 focuses on the approval/validation step at request time.

This control partially overlaps ISM-1927.

ISM-1927 requires that only privileged users who require access can access AD DS/CS/FS and Entra Connect servers. E8-RA-ML1.1 overlaps by requiring validation of privileged access requests, which is a mechanism to ensure that only those who genuinely require access are granted it. ISM-1927 is about the access restriction outcome for specific servers, while E8-RA-ML1.1 focuses on the approval/validation step rather than the technical enforcement on those servers.

This control partially overlaps ISM-2136.

ISM-2136 requires enforcing risk-based access decisions using contextual signals to allow, step up, or deny access to systems and resources. E8-RA-ML1.1 requires validating privileged access requests when first requested, which is a risk-based gate at the point of requesting elevated access. Both address making access decisions based on risk, but ISM-2136 is broader and continuous (per-request, context-driven), whereas E8-RA-ML1.1 is focused on initial approval/validation for privileged access rather than ongoing conditional access enforcement.

This control partially overlaps ISM-2137.

ISM-2137 requires that only an authorised administrator can grant OAuth consent to third-party applications, preventing end users from doing so. E8-RA-ML1.1 requires validation of requests for privileged access when first requested, which aligns with the idea that elevated approvals (including app authorisations that effectively grant access) should be reviewed before being granted. E8-RA-ML1.1 is about validating privileged access requests generally, while ISM-2137 is specifically about third-party OAuth consent controls in identity platforms.

This control supports ISM-0407.

E8-RA-ML1.1 requires organisations to validate privileged access requests when first requested. ISM-0407 supports this by requiring secure records showing who authorised access, when it was granted, and the level of access, which provides evidence that the initial validation/approval occurred. ISM-0407 is primarily about recordkeeping across the access lifecycle, while E8-RA-ML1.1 is the control activity of validating the request itself.

This control supports ISM-1939.

ISM-1939 requires minimising the number of accounts that are members of highly privileged security groups. E8-RA-ML1.1 supports this by validating privileged access requests at the time they are first requested, reducing the likelihood of unnecessary approvals that would otherwise lead to additional highly privileged group memberships. E8-RA-ML1.1 is about access request governance rather than explicitly limiting group membership size.

This control depends on ISM-0432.

E8-RA-ML1.1 requires organisations to validate privileged access requests upon initial request. ISM-0432 supports this by requiring access requirements to be documented in the system security plan, which provides the baseline for deciding whether a privileged access request is justified. ISM-0432 is documentation and planning focused, while E8-RA-ML1.1 is the approval/validation control performed when access is requested.

This control partially overlaps IT.PRO-12.1.

IT.PRO-12.1 requires access privileges to be periodically reviewed and updated to match current roles, duties and business requirements; E8-RA-ML1.1 requires privileged access requests to be validated when first requested, the initial check that periodic reviews then build on.

This control partially overlaps IT.PRO-12.2.

IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; E8-RA-ML1.1 requires privileged access requests to be validated when first requested, supporting that authorisation step.