This article is a guest post written by our interns at RIoT Secure, as part of a multi-part series exploring the evolution of WebAssembly (WASM) and the WebAssembly System Interface (WASI). Each post in this series takes a closer look at the technology’s journey, challenges, and opportunities - with a special focus on what these developments mean for IoT and secure edge computing.
Six Years in the Making - Current State and Roadmap
In a world where programming languages can be run anywhere, regardless of the underlying platform, WebAssembly (WASM) has emerged as one of the technologies that bring this vision closer to reality. Introduced as the fourth official language in 2017, alongside HTML, CSS, and JS, WASM provides a low-level, binary instruction format capable of executing at near-native speed (Titzer, 2025 [5]). With the initial purpose of solving the limitations of compiling C and C++ to JavaScript has quickly evolved into a broader vision: creating a universal, secure, and portable execution environment in which precompilation reduces runtime overhead and applications can seamlessly adapt across diverse systems.
WASM was intentionally designed with applications beyond the browser in mind. Its sandboxing, modularity, and deterministic execution make it a strong candidate for environments such as edge computing, cloud services, and IoT. Its promise of portability across heterogeneous platforms has positioned WASM as a potential “universal execution format” for modern computing (Titzer, 2025 [5]). This portability is what inspired comparisons between WASM’s interface, WebAssambly System Interface (WASI), and POSIX.
Without standardized access to essential system resources, WebAssembly modules remain isolated and limited in scope. This is where WASI plays a critical role, by abstracting platform-specific details it makes it possible to “write once, run anywhere”. WASI provides a set of system calls and APIs that extend WASM capabilities outside the browser, much like POSIX standardized system interfaces for C programs. By defining a consent interface layer, WASI extends WebAssambly beyond the browser by introducing POSIX-like system calls, enabling standalone execution across different host environments (Sok, D’Orazio, Tekin, & Tombroff, 2024 [3]).
The purpose of this blog post is to analyze the evolution of WASI from its introduction through its previews (P1-P3) and its current trajectory toward a long-awaited 1.0 release. This analysis looks to discover its particular emphasis on its implications for IoT. Yet this evolution raises a critical question: WebAssembly promised portability beyond the browser but after six years, why are we still waiting for version 1.0?
A Brief History of WASM & WASI
WebAssembly’s Minimum Viable Product (MVP) was officially standardized in 2017, providing a portable, low-level bytecode capable of running at near-native speed inside the browser. However, while the MVP proved that speed and portability were achievable, it lacked standardized ways to interact with essential system resources such as files, clocks, sockets, etc. Recognizing these limitations, in 2019 industry leaders such as Mozilla, Fastly, Intel, and Red Hat came together to form the Bytecode Alliance. The alliance's purpose was to forge and extend WebAssembly beyond the browser by collaborating on implementing standards: runtimes, specifications and the building of tools needed for a safe, modular and composable execution across environments (Clark, 2019 [1]).
For cloud and server developers, the lack of standardized APIs meant that WASM could not yet serve as a true alternative to containers or native binaries. Each runtime had to invent its own extensions, leading to fragmentation and portability issues. For IoT developers, the challenge is even greater. Constrained devices often run with limited memory and processing power, which makes efficiency and simplicity critical. Without system calls, WASM was stuck as a browser technology, not a universal runtime.
In the aim of implementing these new standards WASI was created. WebAssembly System Interface (WASI), which aimed to do for WASM what POSIX did for C: provide some sort of system facilities across a huge number of non-browser applications, including access to the clock, a filesystem representation, environment variables, command line, etc, enabling programs to “write once, run anywhere”. The launch of WASI intended to provide secure foundations from small embedded divides to large computing clouds.
Three Parallel Developments
Preview 1 (0.1.0)
When WASI was first launched in 2019, it came packaged as Preview 1 (P1). This initial preview was intentionally small, providing a handful of APIs that mirrored basic POSIX-like functionality:
- File I/O (open, read, write, close)
- Sockets and networking primitives
- Clocks and timers
- Random number generation
These capabilities represented the minimum set of system calls needed to run standalone programs outside the browser. At the same time, P1 demonstrated the constraints of WASI’s early design. The APIs were inflexible and modeled directly on POSIX, but without its maturity or scope. Filesystems support, for example, was intentionally restricted to avoid security risks. The design left little room for extensibility, meaning adding new APIs risked breaking compatibility, raising concerns about long-term stability (Clark, 2019 [6]).
From a developers perspective, one might say Preview 1 served as a proof of concept rather than a production-ready standard. It showed that WASM could be extended with system calls in a secure and portable way, but also highlighted its inflexibility to evolve. These limitations set the stage for Preview 2, where WASI started shifting from being a POSIX clone to a modular system capable of supporting interoperability across multiple programming languages.
Preview 2 (0.2.0)
WASI P2 focused on shifting toward a component model, rather than a single API surface, it was restructured into modular interfaces that could evolve independently while still maintaining interoperability. WASI Preview 2 was released in January 2024, providing a stable set of standardized interfaces (Townsend, 2024 [4]):
- wasi-io (I/O primitives)
- wasi-clocks (time and timers)
- wasi-random
- wasi-filesystems
- wasi-sockets
- wasi-cli
- wasi-http
The new modular approach solved several problems P1 did not acknowledge at first. Instead of binding WASI directly to POSIX-like APIs, the component model allowed WASM to act as a polyglot runtime, where modules written in Rust, TinyGo, Python or Java Script could link together without extra code.
Importantly, Preview 1 and Preview 2 target different audiences. While Previews 1 main audience is application developers, Preview 2 is primarily aimed at library implementers. As Brooks Townsend (2024 [4]) mentions, “working with the standard set of WASI interfaces isn't meant for application developers... it provides a stable definition of common interfaces for library developers in each language to build on top of.”. In other words, it aims to eventually let developers use their normal libraries and simply compile to WASI without worrying about low-level bindings.
Preview 2 was a necessary step forward but it wasn't ready for mainstream production use. It is still too low-level for most developers, the APIs introduced are foundational, but they aren’t designed for day-to-day application developers. Developers compiling from languages like Python, Go, or C++ didn't always get consistent WASI 0.2.0 support. While WASI aims to be lightweight, Preview 2 was more resource-hungry. On its own, P2 was too raw, fragmented and resource-heavy to fulfill WASI’s promise of “write once, run anywhere”.
Preview 3 (WASIp3)
The third preview of WebAssembly's System Interface, currently in draft as of 2025, represents a decisive step in getting a production ready standard. Preview 3 addresses the gaps previously shown with P1 and P2 by introducing asynchronous function interfaces as a future of the component model. At its core, WASI P3 introduces an asynchronous ABI, allowing functions to be imported or exported. This design enables runtimes to suspend tasks during blocking calls and allow other tasks to proceed (Dice, 2025 [7]). As a compliment is the addition of generic stream and future types, which make asynchronous computation and data flow explicit. Its mission is to reduce complexity at the specification level.
This shift is critical for cloud and edge computing, where handling thousands of concurrent requests efficiently is essential. Despite its promise, WASI P3 remains a work in progress. The delay highlights the reality that Preview 3 is not yet ready for wide deployment: language support uneven, tooling remains experimental, and production runtimes require costume builds to adopt draft specifications. These challenges show both the ambition of the project and the difficulty of standardizing a system interface that balances portability, performance and security across diverse environments.
Current State
WebAssembly System Interface (WASI) has yet to reach its long-awaited 1.0 release. Despite being introduced six years ago, the project remains in development, with three parallel versions: Preview 1, Preview 2 and the draft of Preview 3. The situation reflects how ambitious the project is and the difficulty of achieving standardization in a rapidly evolving technological landscape.
The most immediate challenge WASI faces is fragmentation across its previews. Preview 1 provided a minimal set of APIs (filesystem, sockets, clocks, random) serving primarily as a proof of concept. Preview 2 shifted the focus towards the component model and modular API, making it possible to compose WebAssembly components across multiple languages. Preview 3, still in draft form, introduces asynchronous ABIs and native concurrency support. While these new features are crucial for cloud and edge environments, they also add yet another layer of complexity to an already complex environment.
The fragmentation extends into the runtime ecosystem. Wasmtime has kept pace with the different previews but must balance experimental adoption of P2 and P3 with the stability users demand. WasmEdge has leaned into cloud-native integration, supporting P2 and experimenting with edge computing use cases. On the other hand, WAMR (WebAssembly Micro Runtime), widely used in IoT contexts, is often tied to P1 because of its lightweight design and constrained environments. Another critical challenge is tooling maturity. While the core specifications evolve rapidly, compilers, libraries and developer frameworks have been slower to catch up. Until WASI interfaces become seamlessly integrated into standard libraries across programming languages developers adoption will remain limited.
On one hand, WASI aims to be a universal execution layer, providing reliable abstractions that work across cloud services, desktops, and embedded devices. On the other hand, its performance overhead can be problematic in resource-constrained IoT contexts where every kilobyte of memory matters. In sum, the current state of WASI reflects both immense promise and ongoing uncertainty. The previews demonstrate a clear pathway towards portability, modularity and concurrency, yet lack an unified 1.0 release.
Implications for IoT and Security
From a security perspective, the stakes are high when implementing WASI. IoT systems are vulnerable. with attackers often exploiting weak firmware or unsafe memory access. WASI’s sandboxing and capability-based security could mitigate these risks by ensuring that modules can only access explicitly granted resources (Clark, 2019 [6]). Another challenge for IoT adoption is binary size. WebAssembly modules, while smaller than traditional containers, can still be relatively heavy. For microcontrollers with limited flash storage, even a small increase in binary size can determine wherever a workload is deployable or not.
Beyond size constraints, the diversity of embedded devices adds future challenges. Embedded devices vary significantly across manufacturers and even within product families, necessitating customized initialization code for microcontrollers and peripherals (Orlando, D’Agati, Longo, & Merlino, 2025 [2]).
After six years, WASI continues in development, raising the question on why a stable 1.0 version has been so difficult to achieve. Its journey from Preview 1’s minimal POSIX-like APIs, through Preview 2’s modular component model, to Preview 3’s asynchronous interfaces reflects both remarkable ambition and the challenges of unifying such a diverse ecosystem. Ultimately, WASI’s success will depend on finding a balance between offering portability while remaining lightweight enough for embedded systems. Standardization at 1.0 will mark a key milestone for WebAssembly adoption beyond the browser. For IoT, this balance isn't optional, it's what will determine where “write once, run anywhere" is truly possible.
Roadmap to WASI 1.0
- Stabilized core API:
The foundation of WASI 1.0 is a small, reliable set of system interfaces - files, sockets, clocks, and randomness. These provide the minimal building blocks for running portable applications outside the browser. Without a stable baseline, higher-level functionality risks fragmentation. - Adoption of the Component Model:
Moving beyond monolithic APIs, the WASI component model allows modular, language-agnostic building blocks. This enables interoperability between modules written in Rust, TinyGo, Python, or C++ while keeping the core runtime small. For IoT, this modularity could allow lean deployments where only the required components are included. - POSIX-like Standardization:
The long-term ambition is to make WASI the POSIX of WebAssembly: a common interface across operating systems, cloud runtimes, and embedded environments. This would give developers confidence that “write once, run anywhere” is not just a promise, but a guarantee backed by standards. - Balancing Portability with Simplicity:
The hardest challenge is ensuring WASI remains lightweight enough for microcontrollers while powerful enough for cloud and edge workloads. Too much complexity risks locking IoT out of the ecosystem, while oversimplification risks losing cloud adoption. Striking this balance will define whether WASI 1.0 succeeds as a universal runtime. - Bridging the Transition:
With Previews 1, 2, and 3 all in use today, the path to 1.0 must also include migration strategies and backwards-compatibility mappings. For IoT devices deployed for a decade or longer, this is not optional — it’s essential to ensure long-term maintainability.
RIoT Secure Perspective
For IoT, stability and predictability matter more than keeping pace with rapidly evolving specs. While WASI is being designed with cloud and server environments in mind, IoT has a different set of priorities: lightweight binaries, deterministic performance, and decade-long lifecycles.
This creates both overlap and divergence. Some WASI goals - like modularity, sandboxing, and portability - map well to IoT. But others, such as increasingly complex component models and asynchronous concurrency, risk outgrowing the constraints of microcontrollers. From RIoT Secure’s point of view, the lack of a finalized 1.0 standard and the absence of an IoT-focused WASI track means that we cannot rely solely on the standard’s timeline. Instead, we must take a pragmatic approach:
- Parallel Development:
building our own lightweight runtime and lifecycle framework optimized for IoT. - Cross-Preview Support:
integrating intelligent mapping layers that allow us to run modules targeting Preview 1, 2, or 3 without breaking compatibility. - Future Alignment:
ensuring that when WASI 1.0 does arrive, devices already deployed in the field can adapt without disruptive rewrites.
For IoT, the challenge is not just waiting for WASI to mature, but ensuring that today’s deployments remain secure and portable while tomorrow’s standards catch up. That’s why at RIoT Secure we focus on bridging the gap: making WASI practical for IoT here and now, while keeping an eye on long-term interoperability.
References
- [1] Clark, L. (2019, November 12) Announcing the Bytecode Alliance: Building a secure by default, composable future for WebAssembly – Mozilla Hacks.
- [2] Orlando, T., D'agati, L., Longo, F., & Merlino, G. (n.d.). A Survey of WebAssembly Usage for Embedded Applications: Safety and Portability Considerations.
- [3] Sok, C., Laurent D'Orazio, Tekin, R., & Dimitri Tombroff. (2024). WebAssembly serverless join: A Study of its Application. 1–4.
- [4] Townsend, B. (2024, January 25). WASI 0.2.0 and Why It Matters. Wasmcloud.com.
- [5] Titzer, B. L. (2025). WebAssembly: How Low Can a Bytecode Go? - ACM Queue, Acm.org.
- [6] Clark, L. (2019, August 21). WebAssembly Interface Types: Interoperate with All the Things! – Mozilla Hacks.
- [7] Dice, J. (2025, March 13). Looking ahead to WASIp3. Fermyon.
This is the first in our multi-part series on WASM and WASI. In the next post - “The Utopian Dream vs. IoT Reality: WASM Binary Size in High-Level Languages” - we’ll explore how binary size impacts real-world IoT deployments, and why portability often collides with the constraints of microcontrollers.
