Exposing a Critical, Systemic Flaw in JWT: Introducing the 'Back to the Future' Attack

Published on: September 30, 2025

Estimated reading time: 4 minutes

Written by: Alberto Batistello

Edited by: Isabella Donders

At Security Pattern, our mission is to help creators of intelligent connected devices to design, implement, and operate their systems with a sustainable security level. It’s our priority to be up-to-date with the latest security trends, as well as performing our own research. Today, we are proud to announce the publication of our latest research which focussed on a critical vulnerability discovered in the widespread JSON Web Token (JWT) authentication standard.

We presented our paper, titled "JWT Back to the future: On the (ab)use of JWTs in IoT transactions," at the prestigious 6th International Workshop on Lightweight Cryptography for Security & Privacy (LightSEC 2025), held in Istanbul, Türkiye, on September 1–2, 2025.

Fig. 1: Alberto presenting our paper at LightSEC 2025 in Istanbul.

We encourage all security professionals, researchers, and technology enthusiasts to review our full paper for a deep technical analysis of this threat and our proposed mitigation protocols: https://zenodo.org/records/17206208

The Protocol Failure: When Efficiency Compromises Security

JWT has become a cornerstone of modern authentication, valued for its lightweight nature and efficiency. When applied to resource-constrained Internet of Things (IoT) devices, this token-based approach offered a welcome alternative to the heavier cryptographic overhead of Transport Layer Security (TLS) mutual authentication.

However, our research confirms that this architectural decision carries a massive security debt.

The core vulnerability stems from the fact that the JWT standard (RFC 7519) does not mandate the inclusion of a crucial security component: a freshness mechanism, such as a cryptographic nonce (a number used once). While a nonce claim is registered, it is optional and, in practice, virtually never enforced. Without this mandatory guarantee of freshness, the Cloud server has no way to verify when a token was actually created.

This lack of mandatory cryptographic hygiene opens the door to far more than simple replay attacks.

Fig. 2: Example of a compromised JWT, with the iat claim set far in the future.

The 'Back to the Future' Supply Chain Attack

We demonstrate a stealthy, long-term supply chain attack that we have dubbed "JWT Back to the future."

The Threat: Our model assumes an untrusted actor, such as factory personnel, gains brief physical access to an IoT device during the manufacturing phase, prior to deployment. Even if the device employs a Secure Element (SE) to protect the private key - a standard defense - we show that the attacker can bypass this hardware security.

The Mechanism: The attacker does not need to steal the private key. Instead, they exploit the unprotected communication channels within the device to manipulate the time perceived by the device under production. The attacker coerces the device's SE to sign a massive batch of tokens with an iat (issued at) claim set far into the future. In our Proof of Concept, we successfully generated tokens valid in 2077.

The Stealth: Once these malicious JWTs are produced, the network is "completely unaware" of their existence, and the device itself retains "no recollection or logs of the happening". The resulting signed tokens are portable and can be used by the attacker to impersonate the legitimate IoT device months or years later. The tokens are cryptographically valid and will be accepted by the Cloud provider when their future timestamp arrives.

Fig. 3 (a): Signal connections between the target and the attacker.

Fig. 3 (b): Picture of the attack experiment.

An Authentication Pandemic: The True Scope

This is not a flaw confined to a single implementation or platform. Because the vulnerability lies within the fundamental JWT protocol structure, it may affect other ecosystems of the JOSE/COSE-based standards.

Our research highlights potential risks may extend across multiple critical sectors:

• Other Token Standards: The flaw affects the CBOR Web Token (CWT) and the Entity Attestation Token (EAT).

• IoT Platforms: Major platforms such as HiveMQ and EMQX are susceptible.

• Critical Infrastructure: Most concerningly, the attack applies directly to the Open Charge Metering Format (OCMF) standard used for recording meter readings from Electric Vehicle (EV) charging stations.

  
  

Mandatory Freshness: The Path Forward

JWT and related token standards, when applied to untrusted supply chains, cannot safely operate without mandatory, non-optional freshness guarantees.

Our paper details several actionable countermeasures that restore the necessary challenge-response logic. These solutions range from using the inherently nonce-protected TLS mutual authentication to implementing specific, robust protocols that leverage the Secure Element’s capabilities or enforce a Cloud-provided nonce mechanism within the token header.

The stakes are high. Without the immediate adoption of these robust countermeasures, mass-market IoT devices and critical infrastructure will remain exposed to massive, long-term, and undetectable impersonation attacks that begin long before they reach the consumer.

For full technical details on the attack mechanism, our Proof of Concept, and the comprehensive suite of countermeasures, please refer to our full research paper, available now at: https://zenodo.org/records/17206208

How to be Involved in Our Work

One way to protect the device from our attack is to establish a secure channel between the Secure Element and the Microcontroller. This is not available on all components. Furthermore, the libraries necessary to run a secure connection are difficult to find, and often are left to implement to the manufacturer.

In Security Pattern, we developed an SCP03 library for both the MCU and the Secure Element. The library can help implementers and manufacturers navigate the complexity of such a delicate part of the system. The library targets a Raspberry Pi as master and the slave code runs on an STM32. 

In order to improve the efficiency of the protocol, we designed and developed a new version of the security protocol, dubbed NSCP (New Secure Channel Protocol), based on Xoodyak lightweight crypto. 

If you are curious, we also developed a RISC-V slave code version! 

Both Master and slave version for the STM32 and RISC-V architectures can be found at the following links:

Repo RISCV (client SCP-03 + NSCP): https://github.com/securitypattern/orshin-corev-secure-element/tree/main

Repo RPi master (SCP-03 + NSCP): https://github.com/securitypattern/orshin-rpi_scp03

Repo STM32 (client SCP-03 + NSCP):  https://github.com/securitypattern/orshin-STM32-client-scp03-nscp

This research was performed as part of the EU-funded project ORSHIN.