A service account credential checked into a config file three years ago, still valid, still accepted by every downstream API, is not a hypothetical — it is the default outcome of how most teams provision machine-to-machine access. A human logging in gets a session that expires in hours and a password policy that forces rotation. A backend service calling another backend service typically gets an API key or a client secret generated once, during setup, and never touched again unless something breaks. That asymmetry is the actual problem this lesson addresses: the credentials protecting the busiest, most privileged traffic on your network are usually the least monitored and the longest-lived, because nobody is sitting at a keyboard to notice they have gone stale.
The fix is not a better secret — it is removing the need for a long-lived one at all. Workload identity systems (SPIFFE/SPIRE being the widely adopted open standard, with cloud-native equivalents in AWS IAM roles for service accounts, GCP Workload Identity, and Azure Managed Identity) issue short-lived, automatically rotated identity documents to a workload based on verifiable facts about that workload — which Kubernetes namespace it runs in, which node attested it, which build pipeline produced it — rather than a static string a human typed into a vault once. Paired with mutual TLS (mTLS), where both sides of a connection present and verify a certificate rather than one side just checking a bearer token, this closes the two biggest gaps in service-to-service auth: a credential that doesn't expire, and a connection where only one party proves who it is.
Analogy🏏Cricket
🏏 Think of it like cricket: A national team's dressing room does not issue every player a laminated all-access pass that works for the rest of their career, checked once at the gate and never looked at again — a player's access to the ground, the nets, and the team hotel is tied to their current central contract and squad selection, re-verified series by series, and it lapses automatically the moment they're dropped or the contract period ends. Contrast that with how some domestic franchises used to hand out season-long staff passes: a masseur or analyst brought in for one tour would keep a working pass that technically still opened doors two seasons later, because nobody owned the job of collecting it back. The national team's model works because the pass itself expires on a schedule tied to a real, current fact — this player is contracted, this series, right now — rather than trusting someone to remember to revoke it. Just as a player's ground access should be re-verified against their current contract status rather than a pass issued once and trusted forever, a service calling another service should present an identity document re-issued against its current, attested state — which cluster, which build, still running — rather than a static key set once at deployment. Just as the national team's system fails closed the moment a contract lapses, a short-lived workload credential fails closed automatically the moment it expires, with no one needing to remember to revoke it. The insight is that identity tied to a current, verifiable fact and re-checked on a schedule is structurally safer than a credential trusted indefinitely because collecting it back was never anyone's job.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.