JWT signing key theft is stealing the private key that an identity provider uses to sign JSON Web Tokens, for example an EdDSA key. With it, an attacker mints valid tokens for any user or service on demand, and because the tokens are cryptographically valid and short-lived, they pass verification and evade static-credential detection. Defend by storing signing keys in an HSM, rotating them, and monitoring token issuance.
What JWT signing key theft is
A JWT is trusted because it is signed by a private key that only the identity provider should hold. Verifiers check the signature against the matching public key and accept anything that validates. That makes the signing key the single most sensitive secret in the system: whoever holds it can forge trust.
How it works and example
The attacker exfiltrates the private signing key, for instance an EdDSA key, from a compromised host, secret store, or memory. They then mint valid, short-lived identity tokens for any principal on demand, impersonating users or services at will. Because each forged token is cryptographically valid and expires quickly, detection tuned for leaked static credentials does not catch it, as seen in a 2026 intrusion.
How to defend against it
Keep signing keys in a hardware security module or managed KMS so they never sit in application memory or on disk, and rotate them on a schedule and after any suspicion. Detect anomalous issuance patterns, bind tokens to additional context such as audience and client, keep verification strict, and be ready to rotate keys and invalidate outstanding tokens quickly.
References
- [1]MITRE ATT&CK: Credential Access (TA0006)(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]MITRE ATT&CK: Steal Application Access Token (T1528)(MITRE ATT&CK)
One stolen signing key forges every identity. Talk to a security expert about where your signing keys live and how fast you can rotate them.