Machine credentials beyond TLS

The shift is bigger than one certificate type

The 47-day schedule gets the attention because it has a date. But the reason behind it, that a credential should live only as long as it is needed, applies to everything a machine carries. The families below are on the same trajectory, and most estates manage each one with a different tool, a different spreadsheet, or nothing.¹

The families

X.509 certificates

The one everyone knows: TLS on servers, mutual TLS between services, client certificates. Issuance, inventory, renewal, revocation, revocation lists and transparency logs. The 47-day post covers the schedule.

SSH certificates

Most SSH access still works by copying a user's public key into a server's authorized_keys file. Keys pile up, nobody remembers whose they are, and removing access means hunting through every host. An SSH certificate replaces that: one SSH authority signs a short-lived certificate saying this user may log in as alice until five o'clock.² No per-host key copying, automatic expiry, central control. Host certificates do the same job in the other direction, so clients stop trusting whatever key a host presented the first time.

Secrets

Database passwords, API tokens, encryption keys. Think of a bank: a vault that stores valuables encrypted, a safe-deposit clerk who issues a temporary key that self-destructs in an hour (dynamic secrets), an armored car that moves valuables to other branches (sync to the platforms that need them), and a teller window that encrypts your deposit without ever seeing it.³

API keys and tokens

The credentials with no expiry and no owner. What matters is exactly that: who owns each one, when it was last rotated, what it can reach, and what breaks if it is revoked.

Workload identities

A workload is a running piece of software: a service, a container, a CI job. Workload identity replaces the permanent badge planted in its config with a temporary one, issued only after the workload proves what and where it is. That proof is attestation; the standard for the resulting identity is SPIFFE;⁴ the credential expires in minutes or hours, not years.⁵

Code-signing keys

A signature on a binary, a container image or a software bill of materials proves it came from you and was not tampered with. Timestamping proves when it was signed, so the signature stays verifiable after the signing certificate expires.⁶ The key behind every signature has a health of its own.

AI agents

The newest family and the sharpest case. Agents appear fast, act with real privileges, and chain calls through other systems. They need identities that are short-lived and policy-gated, issued the same way as every other machine's, so an agent's credential is inventoried, scoped and revocable like any other.⁵

What they have in common

Every family above has the same five-step life. Every one needs an owner, an expiry and an audit trail. And every one has a private half that should stay behind a hard boundary while automation does the rest.

1. DiscoverFind it, name an owner, record when it expires.
2. IssueMint it short-lived, from an authority you control.
3. DeployPut it where the workload actually reads it.
4. RotateReplace it before expiry, on policy, with proof.
5. RetireRevoke or expire it, and remove the old copies.

That is the argument for one inventory rather than seven. Not because one tool must do everything, but because the credentials no single tool owns are the ones that fall through the cracks, and at short lifetimes they fall through faster. trstctl is built as that inventory, lifecycle and audit layer across all of the families above, alongside the secrets engine or in-cluster automation you already run.⁷

The feature pages for SSH, secrets, workload identity and code signing go deeper on each family.