A deployment can start with valid access and lose that access before its last step. A long-running provisioning operation, an approval wait or a queued job can consume the usable lifetime of an execution session. Treat this as a time-boundary review, not a reason to issue a permanently privileged credential.
Draw the timeline before changing the lifetime
Record when the job obtains authority, when it starts changing the target system and when the final verification finishes. Include queueing, manual approval and external operations. A workflow timeout and an identity-session lifetime are different controls; extending one does not necessarily extend the other.
Use the platform's actual identity documentation to identify the applicable lifetime, renewal behavior and trust conditions. Do not assume every runner refreshes a session automatically or that a child process receives updated credentials. Record those behaviors as observations of the specific platform and revision.
Separate waiting from authorized execution
Where supported, avoid obtaining deployment authority before a long unrelated wait. Review whether build, review and deployment can use separate jobs with distinct identities. This is a design option, not a universal pipeline prescription: artifacts, approval identity and configuration must remain traceable across the handoff.
A shorter authorization window can reduce exposure while making interrupted execution more likely. A longer window can accommodate slow operations while leaving authority usable for longer. Select the window with the access owner, based on the necessary actions and supported platform controls rather than convenience alone.
Rehearse expiry without using production as the experiment
Choose an isolated non-production target and a bounded operation whose effects can be inspected. Agree the allowed failure, cleanup owner and stop condition. Never shorten or revoke a shared production session merely to demonstrate a failure.