Non-human identities: The overlooked keys

Management Summary

Honest assessment: In many environments, machine identities are more dangerous than user accounts. Service accounts with standing privileges, hard-coded secrets, eternal tokens, and missing telemetry are perfect entry points – invisible, convenient, often declared “technically necessary.” Anyone serious about Zero Trust must not only verify humans, but workloads, services, and devices as well. The path is clear: consistent inventory, minimal privileges, short-lived credentials, strict secrets rotation, and enforced mTLS – proven by KPIs, not by statements of intent.

Why non-human identities are underestimated

• Invisibility in daily operations: There is no employee who “clicks the wrong thing.” Therefore service accounts rarely appear in awareness programs – and slip through every control.
• Convenience vs. security: Standing privileges and static passwords “just work.” Until they are copied, leaked, or pulled from repos.
• Scaling effect: A compromised build token or IoT certificate opens entire fleets – lateral movement without alarms.
• Lack of ownership: Who “owns” the account? Dev? Ops? Business unit? Without a clear owner, everything gets neglected.

Typical weaknesses

• Hard-coded secrets in code, CI/CD variables, IaC templates → enforced secret scanning, plaintext bans, central secrets store, secrets rotation ≤ 30 days.
• Long-lived tokens/certificates → short-lived, signed workload identities; automatic renewal, revocation on anomalies.
• Overprivileged service accounts → strict scopes, least privilege, time- or event-based access; no shared accounts.
• Missing transport security between services → mandatory mTLS (mutual verification) with automatic certificate rotation.
• No inventory/no telemetry → central registry for machine identities, usage and issuance logs, alerts for “impossible” patterns.

Principles for resilient machine identity

1. Explicit existence: Every non-human identity is registered (owner, purpose, scope, expiration date).
2. Short-lived over comfort: Tokens/certificates live hours–days, not months. Rotation is mandatory, not a project goal.
3. Trust is provable: mTLS + signatures + attestations; no “we believe that …”.
4. Least privilege by design: Permissions are specific, clearly separated, and expire automatically.
5. Detectability: Every use leaves correlation (identity × target × time × source) – otherwise no deployment.

90-day plan

Day 0–15 – Visibility & stop criteria

• Full inventory of all service accounts, tokens, certificates, API keys (incl. owner, scope, expiration).
• Policies: ban hard-coded secrets; minimal lifetimes; mandatory mTLS for internal service-to-service paths.
• Establish baseline KPIs (see below).

Day 16–45 – Hardening & short-lived credentials

• Introduce/standardize a central secrets store; start automated secrets rotation.
• Short-lived workload identities (signed, time-limited credentials) for the top 3 critical services.
• Enable mTLS on critical paths (mutual verification, auto-renew).

Day 46–75 – Automate & delete

• CI/CD gates: builds fail on hard-coded secrets, expired certificates, oversized scopes.
• Privilege diet: reduce overprivileged service accounts; delete unused identities.
• Anomaly detection: unusual usage (time, source, volume) → auto-revoke + pager.

Day 76–90 – Anchor & prove

• Lock in rotation cycles (≤ 30 days tokens, ≤ 90 days certificates – depending on risk).
• Test break-glass process for machine identities (issue, use, revoke, audit).
• Quarterly steering with KPIs; tie budget to impact (e.g., “pinned rate,” “rotation rate”).

KPIs that make maturity measurable

• Inventory coverage: % of registered machine identities with owner, scope, expiration date.
• Rotation rate: % of secrets/certificates rotated within target cycles.
• Short-lived score: Median lifetime of tokens/certificates by criticality.
• mTLS coverage: % of critical service paths with enforced mTLS (incl. mutual verification).
• Scope hygiene: Share of service accounts with minimal privileges (no wildcards, no admin-all).
• Leak/find rate: Number of secrets found per month and time to revocation/rotation.

Anti-patterns

• “Technically necessary” as an excuse for standing privileges – no. Prove the necessity, limit it, compensate the risk.
• “mTLS later” – later means never. Without mutual verification, the “internal” network is an open field.
• “Dev environment only” – attackers love dev: real data models, real keys, little monitoring.
• “We don’t log – data protection” – data protection is not a logging ban. Log sparingly, but verifiably.

Practical checklist

• Enforce secret scanning in all repos/CI pipelines; fail builds on findings.
• Central secrets store with secrets rotation and short-lived leases (just-in-time for services).
• mTLS mandatory for internal services; automatic certificate issuance/renewal.
• Permission reviews for service accounts: minimize scopes, set expirations, assign owners.
• Telemetry requirement: correlate usage per identity; auto-revoke on anomalies.
• Deletion discipline: remove unused machine identities – monthly cadence.

Conclusion: identity is more than human

Anyone who only hardens users builds a steel front door – and leaves the side door open. Machine identities are now the number one realistic attack route: quiet, scalable, often without alarms. With short-lived credentials, strict scopes, mandatory mTLS, practiced secrets rotation, and solid KPIs, gut feeling turns into controlled security. Anything else is expensive hope.

FAQ about blog post