Expiration Criteria

Expiration criteria define when a granted access assignment should automatically end or be revalidated. They are a core control for reducing standing access, especially in workflows where access is requested on demand. Time-bounded access helps limit exposure, improves review discipline, and supports least privilege enforcement.

Expanded Definition

Expiration criteria are the conditions that end or force revalidation of an access grant for a non-human identity, such as an API key, service account, workload token, or delegated agent permission. In NHI governance, the term is broader than a simple calendar deadline: it can include event-based triggers, lifecycle milestones, risk thresholds, or approval expiry. That distinction matters because the same access assignment may need a different expiration rule depending on whether it supports a short-lived deployment, a long-running integration, or an autonomous agent with tool access.

Definitions vary across vendors, but the operational intent is consistent with least privilege and time-bound access patterns described in the OWASP Non-Human Identity Top 10 and the control logic of NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, expiration criteria should be explicit, machine-enforced, and tied to the business reason for access, not left to informal review notes. The most common misapplication is treating expiration as a static date field, which occurs when teams assign a default end date without linking it to revocation, revalidation, or workflow completion.

Examples and Use Cases

Implementing expiration criteria rigorously often introduces operational friction, requiring organisations to weigh tighter access control against renewal overhead and automation effort.

• A CI/CD service account is granted access for a single release window and expires after deployment, unless a pipeline owner revalidates the assignment through a controlled workflow.
• An AI agent receives temporary tool access for a customer support task and the permission expires when the case closes or the agent changes context.
• A third-party integration token is issued with a fixed lifespan and must be renewed only after vendor risk review, aligning with lifecycle guidance in the NHI Lifecycle Management Guide.
• A privileged API key used for incident response is time-bounded and automatically removed after the incident ticket is resolved, reducing standing exposure.
• A secret created for a migration project is set to expire at project cutover, consistent with the lifecycle and secret-handling patterns discussed in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

Expiration criteria are especially useful where the access purpose is narrow, the trust boundary is external, or the identity is expected to be ephemeral by design. They also work well when paired with revalidation checkpoints for human approval, workload attestation, or policy evaluation.

Why It Matters in NHI Security

Expiration criteria are a practical defense against secret sprawl, stale privilege, and forgotten machine access that outlives the system or task it was created for. Without enforced expiry, organizations accumulate access that no longer has a valid business purpose, which expands the attack surface and makes offboarding harder. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes expiry discipline a direct governance gap rather than a cosmetic policy choice. The related exposure patterns are explored in the Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge.

For security teams, expiration criteria also improve auditability because they create a clear expected end state for each access assignment. That makes them important in Zero Trust programs, where persistent access should be the exception, not the norm. Organisations typically encounter the cost of missing expiration criteria only after a token leak, a failed offboarding event, or an audit discovers dormant access, at which point the concept becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations change procurement criteria for AI-native software?
• What breaks when a support programme has unclear selection criteria?
• What do security teams get wrong about token expiration in JWT authentication?
• How should healthcare organisations strengthen identity controls after CISA expiration?