- wolfSSL’s new embedded COSE library targets constrained IoT devices with a 7.5 KB minimal build footprint.
- The embedded COSE library supports post-quantum ML-DSA signing at all three security levels alongside 40 total algorithms.
- Zero dynamic memory allocation means all operations use caller-provided buffers, critical for bare-metal embedded targets.
- A clear path to FIPS 140-3 certification exists through wolfCrypt’s existing Certificate #4718.
- wolfSSL’s new embedded COSE library targets constrained IoT devices with a 7.5 KB minimal build footprint.
- The embedded COSE library supports post-quantum ML-DSA signing at all three security levels alongside 40 total algorithms.
- Zero dynamic memory allocation means all operations use caller-provided buffers, critical for bare-metal embedded targets.
- A clear path to FIPS 140-3 certification exists through wolfCrypt’s existing Certificate #4718.
wolfSSL Launches wolfCOSE, a New Embedded COSE Library
wolfSSL has quietly released wolfCOSE, a new embedded COSE library written in C that brings structured cryptographic messaging to the tightest of hardware constraints. Built on top of wolfCrypt — wolfSSL’s established crypto engine — it implements both CBOR Object Signing and Encryption (COSE, RFC 9052/9053) and the underlying CBOR serialisation format (RFC 8949) in a single, self-contained package. The headline numbers are striking: a minimal build weighs in at just 7.5 KB of .text, the full 40-algorithm build hits 25.6 KB, and the entire COSE message lifecycle fits inside under 1 KB of RAM — wolfCrypt internals excluded.
For anyone working on firmware security, IoT device attestation, or constrained embedded targets, those numbers matter enormously. This embedded COSE library is released under GPLv3, with commercial licensing available directly through wolfSSL for organisations that need it in a proprietary stack.
Why COSE Matters for Embedded Security Right Now
COSE isn’t exactly a household name, but it’s become the de facto standard for signed and encrypted messaging in constrained environments. You’ll find it underpinning CBOR Web Tokens, SUIT firmware update manifests (RFC 9019), remote attestation in IETF RATS architectures, and increasingly in Matter-based smart home devices. Essentially, anywhere that JSON is too verbose and TLS is overkill for a one-shot message, COSE fills the gap.
The problem has always been finding a production-grade C implementation that doesn’t bring a heap allocator along for the ride. Most embedded targets — microcontrollers running FreeRTOS, bare-metal Cortex-M devices, safety-critical automotive ECUs — either have no dynamic allocator or are explicitly prohibited from using one under standards like IEC 61508 or ISO 26262. An embedded COSE library with a zero dynamic allocation model directly addresses that. Every operation works against caller-provided buffers, which means memory usage is deterministic at compile time. That’s not a nice-to-have in safety-critical firmware; it’s a hard requirement.
The Full embedded COSE Library Feature Set
wolfCOSE implements all six message types defined in RFC 9052: Sign1, Sign, Encrypt0, Encrypt, Mac0, and Mac. Critically, it supports the multi-actor variants — multi-signer COSE_Sign and multi-recipient COSE_Encrypt and COSE_Mac — which are needed for scenarios like fleet-wide firmware distribution where a single message needs to be verifiable or decryptable by multiple parties with different keys.
The algorithm coverage is broad. On the signing side you get the full ECDSA suite (ES256, ES384, ES512), EdDSA with both Ed25519 and Ed448, RSA-PSS at three hash lengths, and — most notably — ML-DSA (Dilithium) at all three NIST security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. For encryption, AES-GCM at 128, 192, and 256 bits, ChaCha20-Poly1305, and several AES-CCM variants are supported. MAC coverage includes HMAC with SHA-256/384/512 and AES-MAC. Key distribution handles Direct, AES Key Wrap, and ECDH-ES+HKDF.
That’s 40 algorithms in total. For an embedded COSE library whose full build fits in 25.6 KB, that’s a remarkable range.
Post-Quantum Support Is the Real Story
The inclusion of ML-DSA (formally known as CRYSTALS-Dilithium, now standardised as FIPS 204) is arguably the most significant technical detail here. NIST finalised its post-quantum cryptography standards in August 2024, and the industry is now in the early stages of figuring out how to get those algorithms onto the billions of constrained devices already in the field — or being designed today with 10-year lifespans.
Most of those devices will need to verify signed firmware updates for the foreseeable future. If the signing keys protecting those updates are RSA or ECDSA, they’re theoretically vulnerable to a sufficiently capable quantum computer. ML-DSA is the standardised answer, and wolfCOSE is one of the first production-oriented embedded COSE library solutions to ship it inside a COSE message stack rather than as a raw algorithm primitive.
wolfSSL requires version 5.8.0-stable or newer of its own library to use ML-DSA through wolfCOSE, specifically because that release introduced the wc_ForceZero symbol and the context-aware Dilithium APIs needed for the final FIPS 204 implementation. Earlier 5.x versions can technically be patched, but wolfSSL is steering commercial users toward a support contract for that path.
Quality Bar: Testing and Compliance
The testing infrastructure wolfSSL has built around wolfCOSE is notably thorough for an embedded COSE library that isn’t yet formally classified as a supported product. Continuous integration runs on Ubuntu and macOS across GCC versions 10 through 14 and Clang 14 through 18. There are roughly 240 algorithm combination tests, and code coverage sits at 99.3% for the core wolfcose.c and a clean 100% for wolfcose_cbor.c.
Static analysis is applied at multiple layers: cppcheck, Clang analyzer, GCC’s -fanalyzer flag, and nightly Coverity Scan runs for defect analysis. MISRA C 2012 compliance is checked via cppcheck’s MISRA addon across all code paths, and MISRA C 2023 adherence is enforced through strict GCC warnings and clang-tidy with bugprone, cert, clang-analyzer, and misc rule sets.
That’s a serious compliance posture for any embedded COSE library. MISRA C 2012 is the baseline requirement for automotive software and is increasingly required in medical and industrial IoT contexts. The fact that wolfSSL is applying it from day one, before the library even reaches official supported product status, signals that they’re designing for regulated markets from the ground up rather than retrofitting compliance later.
The FIPS 140-3 Angle
Because wolfCOSE relies exclusively on wolfCrypt as its cryptographic backend — it has no other crypto dependency — this embedded COSE library inherits a clear path to FIPS 140-3 validation through wolfCrypt’s existing Certificate #4718. For government, defence, and healthcare deployments in the US, FIPS 140-3 validation is frequently a hard procurement requirement. Being able to point to a single validated module rather than assembling one from multiple dependencies is a meaningful advantage, and it’s a deliberate architectural choice rather than a happy accident.
A Product in Progress — But a Serious One
wolfSSL is transparent that wolfCOSE isn’t yet an officially supported product. The copyright notice reads 2026, which is unusual and may reflect forward-looking intent or a drafting quirk, but the code is available and functional today. The company states it was “designed from the ground up to meet the same quality standards as the rest of the wolfSSL suite with future adoption in mind” and that it intends to transition wolfCOSE to full supported status as demand grows.
That’s an honest positioning. The embedded COSE library is clearly production-quality in terms of testing rigour and standards coverage, but organisations putting it into shipping hardware will want to have a conversation with wolfSSL about a commercial support contract — particularly if they’re in a regulated industry or need long-term patch commitments.
The embedded security space has been waiting for a well-tested, allocation-free embedded COSE library that doesn’t require porting a full TLS library just to sign a firmware manifest. With post-quantum algorithms baked in from the start and a realistic path to FIPS 140-3, wolfCOSE arrives at exactly the right moment — just as device manufacturers are starting to grapple seriously with what quantum-resistant firmware signing actually looks like in practice. The libraries that get into design cycles now will be the ones running on hardware shipping in 2027 and beyond.
