Point-Of-Use Access

Expanded Definition

Point-of-use access is a delivery pattern for credentials, tokens, or certificates in which the artifact is issued only at the moment a trusted actor needs it. In NHI security, that means access is tied to a specific request, a specific identity, and a specific execution context, rather than being pre-positioned in code, images, or shared storage.

This pattern is closely related to just-in-time privilege, but the terms are not identical. JIT focuses on when privilege is granted; point-of-use access focuses on when the secret or token is delivered. The practical goal is to shorten exposure time, reduce secret sprawl, and make misuse easier to detect. Guidance across vendors is still evolving, but the principle aligns with OWASP Non-Human Identity Top 10 guidance on limiting secret exposure and lifecycle risk. The most common misapplication is treating any short-lived token as point-of-use access, which occurs when the credential is still cached broadly or reused outside the original request context.

Examples and Use Cases

Implementing point-of-use access rigorously often introduces orchestration overhead, requiring organisations to weigh lower credential persistence against added delivery complexity and tighter dependency on the issuing control plane.

• A CI/CD job requests a short-lived token only after the pipeline has been attested and approved, rather than storing a long-lived API key in the build configuration.
• A Kubernetes workload receives a certificate at startup through a workload identity broker, with issuance tied to the pod identity and namespace instead of a shared secret mounted across clusters.
• An AI agent gets scoped access to a data source only for the duration of a single task, reducing the chance that a compromised agent can reuse credentials later.
• A database migration tool fetches a credential from a vault at execution time, then discards it immediately after the task completes, matching the control intent described in the Ultimate Guide to NHIs.
• A third-party automation process is given a token that expires after one transaction, which helps limit downstream exposure if the integration is abused.

These patterns also map to broader identity lifecycle expectations discussed in the Ultimate Guide to NHIs — Key Challenges and Risks and to the access-minimisation emphasis in the OWASP Non-Human Identity Top 10.

Why It Matters in NHI Security

Point-of-use access matters because the largest NHI failures usually start with credentials that persist longer than necessary or exist in more places than intended. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage. That makes narrow delivery controls more than a convenience feature; they are a containment mechanism.

When point-of-use delivery is absent, service accounts, scripts, and agentic workflows can inherit broad reach from a single exposed token. This creates a mismatch between the actual task and the standing access available to perform it. A more disciplined approach supports Zero Trust, but only if the receiving system also verifies identity, scope, and context before issuing the credential. For implementation patterns, organisations can pair this model with identity federation concepts from SPIFFE and cloud-control expectations in CISA Zero Trust Maturity Model.

Organisations typically encounter the need for point-of-use access only after a leaked token, abused pipeline secret, or over-permissioned agent account has already been used to move laterally, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern third-party AI agents that use OAuth access?
• How should teams use reverse proxies for least-privilege access?
• Should identity teams use just-in-time access for NHIs?