Renewal behavior of expired Consul ACL tokens

Short answer

An expired Consul ACL token cannot be renewed in place. Once the TTL elapses, the token is invalid, and the renewal API rejects it. This is consistent with Consul's time-based least-privilege model: a TTL is a hard upper bound on credential lifetime, not a sliding window that can be extended after the fact. The correct operator workflow is to issue a new token and let the old one be garbage-collected (or delete it explicitly).

What is confirmed vs. what is inferred

Confirmed behavior, reproducible on any recent Consul version (this was written against the 1.x ACL system; verify against your exact release):

• Expired tokens are treated as invalid for authentication and authorization.
• Renewal attempts against an expired token fail rather than extending the TTL.
• The token entry can remain visible in listings (consul acl token list) until the internal garbage collector removes it. Visibility does not imply validity.

The part that is an inference rather than a documented guarantee: whether the prohibition on renewing expired tokens is a frozen design commitment or simply current behavior that could change in a future release. The behavior aligns with least-privilege intent — allowing post-expiry renewal would make TTLs advisory rather than enforceable — but if your automation depends on this never changing, pin and test against the Consul versions you run rather than assuming a permanent contract.

Does garbage-collector timing open a renewal window?

No. The GC interval only controls when the expired token's record disappears from the registry; it does not affect validity. A token that expired one second ago is just as unrenewable as one that expired yesterday, even if it still shows up in token list. Do not build automation that races the GC hoping to renew a token that "still exists." Existence in the listing and validity are decoupled.

Recommended operator workflow

1. Renew before expiry. If a workload needs continued access, schedule renewal comfortably inside the TTL (for example at 50–70% of lifetime) so transient failures leave retry room.
2. On any renewal failure, treat it as expected and create a replacement token with the same policies/roles, then distribute it through your normal secret path.
3. Optionally delete the expired token explicitly instead of waiting for GC, to keep listings clean in long-lived clusters.

Verifying this yourself

A two-minute experiment confirms the behavior on your exact version:

# Create a short-lived token
consul acl token create -policy-name my-policy -ttl 10s

# Wait past the TTL, then attempt renewal
sleep 15
consul acl token renew -accessor-id <accessor-id>
# Expected: an error; the token is not extended

# Confirm the record may still be listed while invalid
consul acl token list

# Issue a working replacement
consul acl token create -policy-name my-policy -ttl 1h

If renewal after expiry ever succeeds in a future release, this test will catch it during upgrade validation — which is the right place to detect a semantics change, rather than in production automation.

Bottom line

Treat renewal failure of an expired token as expected, not as a bug or a transient error worth retrying. Renew early, replace on expiry, and never infer usability from a token's continued presence in the registry.