ISM lookup / System access

ISM-2141 · September 2026

Application and workload credentials

Guidelines for system access / Credential management / Application and workload credentials

Official control wording

Applications and workloads use short-lived dynamically issued credentials in preference to long-lived static credentials.

Applicability

  • Non-classified (NC)
  • OFFICIAL: Sensitive (OS)
  • PROTECTED (P)
  • SECRET (S)
  • TOP SECRET (TS)

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.

// Latticework implementation guidance · partial coverage

Inspect credential issuance, lifetime and sharing

Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.

Implementation steps

  1. Inventory workload and service identities, including credentials held outside Kubernetes. Prefer short-lived projected or dynamically issued credentials and explicitly set the intended audience.
  2. Review legacy service-account token Secrets, default ServiceAccount use and credential sharing across workloads/environments. Test admission policies before rollout; assess existing credentials separately.

Evidence to retain

  • Keep an identity-to-workload/environment inventory, credential issuer configuration, token lifetime/audience evidence and revocation/rotation records without recording secret values.
  • Keep policy configuration and admission results, plus a separate existing-credential review. Demonstrate uniqueness and dynamic issuance directly; non-default account names do not establish either.

What the mapped checks can establish

Admission results show whether new or updated legacy service-account token Secrets are rejected or reported; background scanning is disabled. They do not prove existing tokens are removed, projected tokens are used, token lifetimes are short, or application and external credentials are dynamic.

Responsibility boundary

Platform team: token issuer and admission configuration. Workload team: identity allocation and application secrets. Organisation: credential policy, break-glass custody and access reviews.

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

  • kyverno: ism-privileged-access-block-legacy-sa-tokens

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-2141. 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.