We are announcing YAFFS/Secure, a version of YAFFS that adds hooks for encrypting and authenticating the data a device writes to flash. It is designed to work alongside hardware-backed trusted execution environments such as ARM TrustZone, so that a device can protect what it stores without the file system ever holding the keys.
Why we built it: storage is now a regulatory problem
The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — sets baseline cybersecurity requirements for products with digital elements sold into the EU. Its main obligations apply from 11 December 2027, and the reporting obligations for actively exploited vulnerabilities have been in force since 11 September 2026. For most embedded product teams, that deadline is now inside the development cycle of the product they are currently designing.
Two of the essential requirements in Annex I of the Act bear directly on how a device stores data. Products must protect the confidentiality of stored data — the Act points to encrypting data at rest using state-of-the-art mechanisms — and must protect the integrity of stored data, firmware and configuration against modification that the user has not authorised.
On an embedded device, “data at rest” overwhelmingly means the flash. If the file system cannot encrypt and authenticate what it writes, those requirements have to be met somewhere else: usually bolted on above the file system, file by file, by application code that was not written with that job in mind. That approach tends to leave gaps — temporary files, logs, configuration written by a library you did not write — and gaps are exactly what an assessment will look for.
What YAFFS/Secure adds
YAFFS/Secure adds hooks on the path between the file system and the flash. Data on its way to the medium can be encrypted before it is written, and can carry authentication data that is verified when it is read back, so that modified or substituted content is detected rather than quietly handed to the application.
Deliberately, YAFFS/Secure does not ship a fixed cipher of its own. The hooks let the integrator supply the cryptography, which matters for several practical reasons:
- You can use crypto you have already validated. If your product needs a certified implementation, or one that has already been through your own review, you use that one rather than arguing about ours.
- You can use the hardware you paid for. Most modern SoCs have a crypto accelerator. A fixed software implementation inside the file system would leave it idle.
- Algorithms can change; the file system need not. “State of the art” is a moving target over a product lifetime that may run a decade. Changing the algorithm should not mean changing your storage stack.
- The file system never needs to hold key material. Which leads to the next point.
Working with TrustZone and other trusted execution environments
The hooks are designed so that keys and cryptographic operations can live inside a trusted execution environment — the ARM TrustZone secure world, or an equivalent on other architectures — rather than in the operating system that runs the application.
YAFFS carries on doing what it has always done in the normal world: managing blocks and pages, wear levelling, garbage collection, and recovering cleanly from power loss. When data needs to be encrypted or verified, it calls across into the secure world, which does the work and hands back the result. The keys stay on the far side of that boundary. An attacker who compromises the rich OS gets ciphertext and an oracle, not the keys, and cannot forge data that will pass verification on the next boot.
This is the structure that makes a genuinely secure device possible rather than merely a device with encryption in it. It is also the structure that is straightforward to explain to an assessor, which is not a minor consideration between now and December 2027.
What it does not do
YAFFS/Secure is a component, not a compliance certificate. The Cyber Resilience Act applies to whole products, and meeting it involves secure boot, a working update mechanism, vulnerability handling processes, a software bill of materials, and a good deal else that no file system can supply.
What a secure file system does is take the storage-related requirements off the list of problems you have to solve yourself, and give you something concrete to point at when you are asked how data at rest is protected. The rest of the product is still your responsibility.
Availability
YAFFS/Secure is available now for evaluation by commercial licensees. If you are working towards a Cyber Resilience Act deadline and want to talk through how it would fit your design, or you would like a copy to evaluate, get in touch.