Rotation & Expiry

Know what is overdue.Before it is stolen.

The best credential is the one that expires before anyone can steal it. Trustivan tracks age, last rotation and expiry for every credential it inventories, flags the overdue, the expiring and the reported-exposed, and routes each finding to its owner. It does not rotate or vault customer credentials — your people and your vault do.

Rotation, expiry & exposure findings: availableRotating or vaulting at a provider: future capabilityM3 · Credential Security

Credential metadata from AWS IAM and Kubernetes · never a secret value

Strategy

Short-lived first. Vaulted second. Static last.

A credential hierarchy that turns rotation from a recurring chore into an exception you can count.

Short-lived & federated

OIDC, workload identity and STS sessions that expire in minutes and never need a rotation ticket

Vault-managed

Secrets that must be static live in a vault with leases, rotation policies and access evidence

Static, tracked

What remains gets an owner and a rotation threshold — and Trustivan flags it the day it is overdue

How it works

Findings that know who answers, and what the credential unlocks

Credential ↔ identity mapping is what makes a rotation finding actionable: you see the identity that holds the credential, the owner who answers and the resources it reaches.

Rotation

Rotation findings with the owner and the reach attached

Rotating a credential is only safe when you know what depends on it. Because each credential is mapped to its identity, a rotation-overdue finding arrives with the owner who answers for it and what that identity can reach — and a proposal to rotate is approved by a second person. The rotation itself happens at the provider, by a person.

  • Age, last rotation and threshold per credential, grouped by owner so the queue lands with the right team.
  • Last use where AWS reports it, for roles and access keys; everywhere else it stays unknown.
  • No rotation executor: Trustivan records and approves the proposal; it never rotates at the provider.
Available
Exposure

An exposed credential is a rotation you cannot schedule

When a scanner you already run reports an exposure through the ingestion API, Trustivan matches it to the credential and identity it belongs to and raises a finding. Where ingested activity shows an expired credential still in use, that is a finding too. Measuring vault coverage is a future capability: the Vault connector reads roles and policy names, never secret data.

  • Vault connector available today: HashiCorp Vault — AppRoles, identity entities, policy names and auth mounts, never secret data.
  • Findings by environment and owner, so the next clean-up wave is obvious.
  • No scanner ships: exposures arrive from the tools that find them.
View vault integrations
Federation

Replace standing keys with identities that prove themselves

GitHub Actions to AWS through OIDC, Kubernetes workload identity to a cloud, SPIFFE SVIDs between services — wherever a platform can issue short-lived credentials, the static key is the risk. Trustivan keeps counting the static keys that remain and flags each one as it ages; recommending and generating the migration is a future capability.

  • Static keys ranked by age and by the reach of the identity that holds them.
  • Role trust on the graph, so the account a federated workload would land in is visible.
  • Static keys that remain stay flagged until the finding clears.
See the DevOps & CI/CD solution
  • AWS IAMRoles, machine users, access-key metadata, trust, inline policy statementsAvailable
  • GitHubApp installations, bot members, repositories and their visibilityAvailable
  • HashiCorp VaultAppRoles, machine identity entities, auth mounts, policy namesAvailable
  • KubernetesService accounts, role bindings, workloads that run as themAvailable

What you get

Every overdue, expiring and exposed credential, counted

Rotation, expiry and exposure become numbers you can defend — and each number decomposes into the credentials behind it.

Credential age report

Every credential’s age, last rotation and expiry by identity, owner and environment

Rotation findings

Rotation overdue raised per credential, with the identity and owner that answer for it

Exposure findings

Credentials reported exposed through the ingestion API, matched to their identity — no scanner ships

Agent credential lifetimes

Agent runtime credentials issued for 1 to 90 days, shown once, stored as a digest, revocable

Expiry warnings

Credentials approaching or past expiry, with the identity and owner listed

Finding evidence

Credential metadata and finding history for auditors and incident reviews — never a secret value

Example

A static key doing a job federation could do better

The most valuable rotation is the one you never have to do again.

HighLong-livedRotation overdueProduction

Static access key 498 days old, still used by a deployment pipeline

Why
A 498-day access key on a deployment machine user is past the rotation threshold and reaches production
What
aws-access-key/AKIA…Q2F (access key of machine user gha-deploy-web)
Who
Owner: Web platform team (declared by tag)
Where
AWS account prod-core · environment prod
How
Never rotated since creation; AWS reports the key last used 40 minutes ago
Blast radius
Deploy permissions on 3 resources · read on 1 high-impact configuration resource · an upper bound
Recommendation
Move the pipeline to an OIDC-assumed role, then delete the key at AWS
Action
Assign to owner · propose rotation for second-person approval · the finding clears when the key is gone
Evidence
Access key metadata · key last used (AWS-reported) · effective-access path
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

Make long-lived credentials the exception.

See how TRUSTIVAN connects identity, credential, access, agent and action context into one control plane.