ISM-1883 · September 2026
Privileged access to systems
Guidelines for system access / Identity and access management / Privileged access to systems
Official control wording
Privileged user accounts explicitly authorised to access online services are strictly limited to only what is required for users to undertake their duties or functions.
Applicability
These are ASD’s applicability markings. Select and tailor controls for your system’s risk, classification and operating context with the system owner and authorising officer.
ASD Essential Eight applicability: ML1 · ML2 · ML3. A profile marking does not establish maturity attainment.
// Latticework implementation guidance · partial coverage
Review privileged human access against duties
Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.
Implementation steps
- Inventory privileged human identities and the online services they can access. Have service owners approve the minimum permissions needed for each role.
- Review cluster-admin bindings and wildcard RBAC grants, test reduced permissions, and remove unnecessary access through a reviewed change. Include external identity-provider and application roles.
Evidence to retain
- Keep dated identity and RBAC exports, role-to-duty approvals, removal records and scan/admission results.
- Link technical permission findings to human account ownership, authorisation and lifecycle reviews. ServiceAccount counts alone cannot establish this control.
What the mapped checks can establish
RBAC findings show Kubernetes permission breadth and cluster-admin assignments; they do not establish which privileged human accounts require online-service access, authorisation workflow, human account lifecycle or external systems.
Responsibility boundary
Platform team: Kubernetes RBAC and identity integration. Service owners: duties and permissions. Organisation: privileged-access authorisation, human account lifecycle and review cadence.
The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.
Mapped checks to inspect
- kubescape: ism-no-cluster-admin-binding
- kubescape: ism-no-wildcard-permissions
- kyverno: ism-privileged-access-block-cluster-admin-binding
These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.
Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.
Official source
ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details
Control source identifier: ism-1883. Check the official release before relying on this snapshot for an assessment.
Official control wording and applicability: Australian Signals Directorate, © Commonwealth of Australia 2026. September 2026 ISM, OSCAL v2026.09.4, reproduced under CC BY 4.0. Formatting is adapted for this website.
Latticework Systems’ implementation guidance is our interpretation. Provenance and scope.