Mongoose
EU CRA compliance starts with the networking stack
The EU Cyber Resilience Act requires manufacturers of connected products to ship without known vulnerabilities, support secure remote updates, and maintain a vulnerability handling process for the product's lifetime.
Mongoose gives you the infrastructure to meet those obligations - built-in TLS 1.3, signed OTA firmware updates with rollback, daily automated fuzzing, and AI-assisted security review on every code change.
What CRA requires - and how Mongoose delivers
No known exploitable vulnerabilities at shipment
CRA Annex I §1(a). Products must ship with no known exploitable vulnerabilities.
Secure communication - confidentiality and integrity
CRA Annex I §1(d,e). Products must protect data in transit.
Secure remote firmware updates
CRA Annex I §1(h) and Art. 13. Products must be updatable; updates must be secure.
Minimal attack surface
CRA Annex I §1(b). Products must minimise attack surfaces.
mongoose.c and mongoose.h - no external package dependencies to install or manageVulnerability handling process
CRA Annex I Part II. Manufacturers must have a documented vulnerability handling process.
Access control and authentication
CRA Annex I §1(c). Products must protect against unauthorised access.
The alternative: owning it yourself
Building a private embedded web server means your team inherits the entire security surface indefinitely. Under CRA that means: running your own fuzzing infrastructure, triaging every incoming security report, writing fixes, verifying them, distributing patches to devices already in the field, and notifying customers - for the lifetime of the product, with documented processes and timelines.
Mongoose externalises that to a team that does it as a full-time job. You get a maintained, tested, security-reviewed networking stack, and your team focuses on your product.
Frequently asked questions
Does Mongoose fully satisfy CRA for my product?
Mongoose covers the networking layer - the part of your product that handles communication, remote updates, and web interfaces. CRA covers the whole product. Using Mongoose removes the hardest part of the security surface, but you still need to address your application logic, hardware interfaces, and process requirements (SBOM submission, incident reporting, etc.).
What is the SBOM entry for Mongoose?
Mongoose is two files with no external package dependencies. The built-in TLS stack vendors six small crypto routines inline (micro-ecc, BearSSL RSA, x25519, SHA-1, SHA-256, MD5), all under permissive licences. Your SBOM has one top-level entry plus those six sub-components - no transitive package graph to resolve or audit.
How does Mongoose handle vulnerability disclosure?
Cesanta reviews security reports, prepares fixes, and notifies commercial customers before public CVE disclosure. This gives connected device manufacturers time to deploy patches to devices in the field before vulnerabilities are publicly known.
Does Mongoose work on our MCU?
Mongoose runs on any platform with a C compiler. Built-in OTA supports STM32 (H5, H7, F series), NXP IMXRT, ESP32, RP2040/2350, Renesas RA, WCH, and others. For platforms without built-in OTA support, the MG_OTA_CUSTOM path lets you integrate Mongoose's update logic with your own flash driver.
Is commercial support available?
Yes. Commercial licences include private security notifications, maintenance SLAs, and support for specific product lifetimes. Contact us to discuss your requirements.
Ready to evaluate?
Two files. Drop them into your project and start building.
Get started Talk to us about CRA