What is Long-Lived Secret Risk?

Definition

Long-lived secret risk is the exposure created when credentials remain valid for extended periods — months, years, or indefinitely — without rotation or expiry.

Long-lived secrets multiply the impact of any leak: a stolen credential remains useful to adversaries until it is rotated or revoked. In many environments, that's never.

In simple terms:

A long-lived secret is a leak waiting to happen — and the longer it lives, the bigger the eventual impact.

---

Why It Matters

• Most secrets in legacy environments are long-lived.
• Long-lived secrets are routinely leaked (vendor breach, code commit, log).
• Once leaked, blast radius spans the secret's lifetime.
• Modern alternatives (short-lived tokens, federation) are increasingly available.

---

Examples of Long-Lived Secrets

Cloud

• AWS IAM access keys (no expiry).
• GCP service account JSON keys (10-year default).
• Azure SP secrets (1-2 year typical).

Vendor APIs

• OpenAI / Anthropic / Stripe API keys (no expiry).
• Twilio auth tokens.
• SendGrid keys.

Code Forges

• GitHub PATs (up to "never expires").
• GitLab PATs.
• Atlassian API tokens.

Encryption

• Encryption keys without rotation.
• TLS certificates with multi-year validity.
• SSH host keys (unrotated for years).

AD

• Service account passwords (manually rotated rarely).
• Krbtgt password (often rotated yearly or less).

Other

• SAML signing certs (multi-year).
• Webhook signing secrets.

---

Why Long-Lived Secrets Persist

1. Rotation Is Painful

• Manual; risk of breaking dependencies.

2. No Expiry Available

• Many APIs offer "never expires" option.

3. Multi-Consumer Risk

• Rotation requires updating many consumers.

4. Lack of Inventory

• Don't know secret exists, let alone rotate.

5. No Owner

• Nobody to rotate it.

6. Compliance Gaps

• Frameworks didn't historically enforce.

7. Legacy Code

• Predates secret managers / federation.

---

Risks

1. Long Window of Compromise

Once leaked, attacker has indefinite access.

2. Vendor Breach Blast Radius

Vendor leaks 5-year-old key → 5 years of access exposure.

3. Insider Risk

Departing employee retains access.

4. Audit Findings

"Credential not rotated in X years."

5. Compliance Violations

PCI, SOC 2, ISO call out cadences.

6. Forensic Complications

Stale credentials with stale audit logs.

7. Complacency

Long-lived secrets create false sense of stability.

---

Real-World Examples

1. SA Key Leaked from Old Repo

Service account JSON key created 2018; leaked from archived repo 2024; still valid. Adversary used immediately. Mitigation: rotation + inventory + WIF.

2. PAT in Old Script

GitHub PAT issued "never expires" in 2020 by departed engineer; found in legacy script; abused. Mitigation: PAT expiry policy; periodic audit.

3. Vendor Breach Cascades

Vendor breach exposed customer API keys. Customers using long-lived keys had years of exposure. Customers using rotated keys had limited window. Lesson: rotate.

4. Krbtgt Stuck for 5 Years

AD krbtgt unchanged for 5 years; Golden Ticket attack feasible long after AD compromise. Mitigation: twice-annual krbtgt rotation.

5. Cert Multi-Year

5-year TLS cert with weak signing; couldn't easily replace. Migration to ACME automation enabled 90-day certs.

---

Mitigation Approaches

1. Rotation

Schedule rotation; automate; reduce lifetime.

2. Federation

Replace static secrets with workload identity federation. No secret to live long.

3. Short-Lived Tokens

OAuth access tokens (≤ 1 hour); refresh tokens (rotated on use).

4. Managed Identity

Cloud-native; tokens auto-rotated.

5. Cert Authority for SSH

Short-lived SSH certs replace long-lived keys.

6. ACME for TLS

Automated 90-day cert renewal.

7. Rotation on Leaver

Anyone leaving who touched a secret triggers rotation.

8. Rotation on Suspicion

Any security signal triggers rotation.

9. Secret Manager Integration

Vault rotates and serves at runtime; consumers don't need to know.

---

Best Practices

1. Inventory all secrets and their lifetimes.
2. Set expiry on all new secrets where possible.
3. Rotation cadence by sensitivity.
4. Federation for cloud workloads — eliminate static.
5. OAuth + short-lived for vendor APIs.
6. PAT expiry policies (90 days max).
7. Cert automation (ACME, cert-manager).
8. SSH cert authority instead of long-lived keys.
9. Krbtgt rotation twice a year.
10. Leaver-triggered rotation.
11. Monitoring for stale secrets.
12. Audit + compliance evidence.

---

Checklist

• Secret inventory + lifetimes?
• Expiry default on new secrets?
• Rotation cadence per sensitivity?
• Federation for cloud workloads?
• OAuth short-lived for vendor APIs?
• PAT expiry policy?
• TLS auto-renewal?
• SSH cert authority?
• Krbtgt rotation cadence?
• Leaver-triggered rotation?
• Monitoring for stale secrets?
• Audit / compliance evidence?

---

How Forestall Helps

Forestall:

• Identifies long-lived secrets across cloud / SaaS / AD / code.
• Tracks rotation cadence.
• Recommends migration to federation / short-lived alternatives.
• Tracks remediation as KPI.

---

Frequently Asked Questions

What's "long-lived"?

Context-dependent. Cloud: > 90 days for keys is long-lived. TLS: > 1 year is long-lived (90 days now best practice). PATs: > 90 days.

Can I have any long-lived secrets?

Some are unavoidable today (e.g., root CA keys). Minimize, isolate (HSM), monitor.

Is federation always preferable?

When the platform supports it, yes — eliminates the secret entirely.

How fast can I migrate?

Per-platform. Cloud: months for SA keys → WIF. SaaS: depends on vendor support.

What about rotation breaking dependencies?

Use dual-secret pattern; test in non-prod; monitor.

---

Conclusion

Long-lived secrets multiply the impact of every leak. Inventory, set expiry, rotate routinely, and migrate to federation / short-lived tokens / managed identity / cert automation wherever possible. With short-lived secrets and federation as defaults, leaks become contained events rather than year-long compromises.