Compliance
HurricaneOS and EU regulation
Three EU regimes touch connected devices, and which one binds you depends on what you do. If you operate a fleet in a covered sector, NIS2 applies to you. If you place products on the market, the Radio Equipment Directive and the Cyber Resilience Act apply to you. Some organisations are both. This page is split the same way, because the obligations are not interchangeable. It is a good-faith technical mapping, not legal advice.
The regulations at a glance
| Regulation | Who it binds | Status |
|---|---|---|
| NIS2 — Directive (EU) 2022/2555 | Operators of essential and important services | In force. Poland's UKSC amendment applies from 3 April 2026 |
| RED cybersecurity delegated act (EU) 2022/30, Art. 3.3(d)(e)(f) | Manufacturers placing radio equipment on the EU market | Mandatory since 1 August 2025 |
| Cyber Resilience Act — Regulation (EU) 2024/2847 | Manufacturers of products with digital elements | Article 14 reporting applies since 11 September 2026; full requirements from 11 December 2027 |
One caveat worth knowing, because it is the detail most vendors omit: the harmonised standards EN 18031-1/-2/-3 were listed in the Official Journal with restrictions in January 2025. The "rationale" and "guidance" sections do not confer presumption of conformity, so the standards route is narrower than a bare citation of EN 18031 implies. Plan for that rather than discovering it at assessment.
01
If you operate a fleet — NIS2
NIS2 places obligations on operators, not on software. If you run essential or important services in a covered sector, you are the entity the directive names, and only you can be compliant. No operating system can be "NIS2 compliant" on your behalf, and any vendor who tells you otherwise has not read the directive.
What a platform can do is carry the weight of the technical measures NIS2 expects of you, and give you the evidence to show you have them. Below is Article 21(2) — the ten measures every covered entity must take — against what HurricaneOS delivers.
We use three honest labels:
- Provided
- the platform does this by default; you inherit it.
- Supported
- the platform gives you the mechanism, but you must configure, operate or extend it.
- Yours
- an organisational obligation the platform cannot discharge for you. We say so rather than pretend.
| Art. 21(2) measure | HurricaneOS | What we actually do |
|---|---|---|
| (a) Risk analysis and IS security policies | Yours | Your risk assessment and policy set. We supply the fleet inventory, OS version state and configuration baseline a device-layer risk analysis needs as input. |
| (b) Incident handling | Supported | Health monitoring and automatic rollback on failed boot at the OS and hardware layer. Detection and first response for the device estate; your SOC owns the rest. |
| (c) Business continuity, backup, DR, crisis management | Supported | A/B updates mean a failed update reverts without a site visit, and a unit can be factory-reset and re-provisioned cleanly without reflashing. Backup of your application data and your crisis plan are yours. |
| (d) Supply-chain security | Supported | Every image you build is scanned for known vulnerabilities (CVEs), with findings per service by severity. You still assess us as your supplier. |
| (e) Security in acquisition, development, maintenance; vulnerability handling | Provided | Monthly security updates, CVE backports against your specific board, verified OTA delivery, and a documented disclosure contact. The core of what the subscription buys. |
| (f) Policies to assess effectiveness of risk-management measures | Supported | CVE scan results on every build, OS version and update history per device, and device health data in your dashboard. The assessment against your own policy is yours. |
| (g) Basic cyber hygiene and security training | Yours | Staff training is an organisational duty. The platform reduces the surface: an immutable root filesystem means an operator cannot casually weaken a device. |
| (h) Cryptography and, where appropriate, encryption | Supported | Device-to-cloud channels are encrypted and mutually authenticated (mutual TLS), using a device identity key held in a TPM 2.0. Encryption of application data at rest is not part of this mapping; ask us what applies to your hardware profile. |
| (i) HR security, access control, asset management | Supported | Console access per account and a complete, authoritative device asset register. HR security and your identity provider are yours. |
| (j) Multi-factor authentication, secured communications | Supported | Mutually-authenticated, encrypted device-to-cloud channels (mutual TLS, hardware-backed device identity). Console sign-in uses individual accounts. MFA across your own workforce is yours. |
Get Started
See HurricaneOS in action
Book a 30-minute demo, or ask about a trial on a board we certify or a leased unit. No commitment to talk.
02
If you place products on the market — RED and CRA
This is the shorter half deliberately. Our primary customer operates a fleet; if you are a manufacturer, the platform still carries real weight, but the conformity work is yours and we would rather scope it with you on a call than imply a mapping we have not done against your specific product.
What binds you, and when. Since 1 August 2025, cybersecurity under RED Article 3.3(d)(e)(f) is mandatory for new wireless connected products placed on the EU market — without it you cannot CE-mark and sell. Under the CRA, Article 14 vulnerability and incident reporting has applied since 11 September 2026, and it reaches products already in the field, not only new ones. The full secure-by-design and lifecycle obligations arrive 11 December 2027.
- Network protectionRED 3.3(d). Devices ship with no open management interface. Applications run isolated in containers, and the control plane accepts instructions only after mutual authentication.
- Data and privacy protectionRED 3.3(e). Device identity is a key generated and held in a TPM 2.0, and the identity is designed so it cannot be copied to another device, so traffic is tied to one specific genuine endpoint. Transport is authenticated and encrypted; per-application storage is isolated.
- Protection against fraudRED 3.3(f). Each device holds its own identity key in a TPM 2.0 and the identity is designed so it cannot be copied to another device; the control plane accepts a device only after mutual authentication.
- Secure by defaultCRA Annex I. The device starts in its hardened state, with an immutable base a compromised application cannot rewrite.
- Updates across the product lifetimeCRA vulnerability handling. Monthly OS security updates over the air to the whole fleet, with automatic recovery to a known-good state if an update fails.
- Evidence for reportingCRA Article 14. CVE scan results on every build, and a record of deployments and of OS version and update history per device — what a 24-hour early warning and 72-hour notification require you to have on hand.
03
Where we are your supplier, not your platform
When you assess your supply chain, we are in it, and you are entitled to evidence rather than assurances. What we will give you:
- our EU jurisdiction and hosting (EU-hosted, within the EEA) in writing;
- the CVE scan results for every image you build, per service and by severity;
- our vulnerability-disclosure and security-update cadence, contractually;
- notification timed so that if a vulnerability in the OS affects your fleet, you learn in time to meet your own deadlines — NIS2 Article 23 or CRA Article 14, both of which run on 24 hours then 72.
04
What we will not claim
Consistent with how we talk about security everywhere else on this site:
- We do not claim HurricaneOS "is compliant" with any of these regimes. Compliance attaches to you; the platform is a means to it.
- We do not claim the platform discharges your organisational measures — training, governance, your own risk assessment, management accountability.
- We do not claim immutability or hardware-backed device identity are distinctive. They are table stakes, and they are listed here because the regulations ask for them — not as differentiators.
- We do not claim tamper detection as a platform property. A TPM resists key extraction, which is a different thing from detecting physical intrusion. Enclosure-level tamper response is available only on hardware we build ourselves, specified per project.
05
Hardware requirement
A hardware root of trust is not optional here. We require TPM 2.0 to certify a hardware profile — a board without it cannot provision securely, so we do not support it. That is what lets the claims above apply to every supported device rather than to a subset, and it is worth checking against your bill of materials early if you are bringing your own hardware.
06
Report a vulnerability
If you believe you have found a security vulnerability in HurricaneOS or on this website, email contact@globalstorm.cloud.
Include enough detail to reproduce it, and give us reasonable time to respond before you disclose it publicly.
The same contact in machine-readable form: /.well-known/security.txt
Talk to us
Tell us your sector, whether you operate or manufacture, and roughly how many gateways, and we will map these measures against your specific deployment. Your obligations under these regulations and their national transpositions are for you and your counsel to determine.
Talk to us