Vibhu Bhutani | Softweb
Solutions |
July 10, 2026 | 6 min read
Whether you are in the EU, UK, or US, IoT security is now a must. Here’s what’s changing, how it affects your products, and how you can stay ahead.
For two decades, IoT security was just recommended. Now, it’s required by law. Since 2024, the EU, UK, and US have introduced strict cybersecurity rules for connected products. These requirements are coming together quickly. And many manufacturers may not be ready for how fast things are changing.
If you build connected products or manage a lot of devices using an IoT platform, the rules have changed in a big way. It’s no longer a question of whether you should invest in security. The challenge is to make sure your system can meet these overlapping global rules without duplicating effort and cost.
Three major regulatory milestones have landed in the span of 18 months:
This was the world’s first law to make IoT security mandatory. It bans default passwords, requires companies to be open about security problems, and demands transparency about software updates. Companies that break the rules can face fines of up to £10 million or 4% of their global revenue. These rules are already being enforced.
The FCC introduced a new cybersecurity label for IoT devices. While it’s optional for most commercial sales, a government order makes it required for any IoT products the US government buys starting January 2027.
This is the biggest change yet. Any product with digital features sold in the EU must comply. Companies need to start reporting vulnerabilities by September 2026, and after that, products that don’t meet the rules cannot be sold. Fines are up to €15 million or 2.5% of your global revenue.
It might seem like you have plenty of time with the December 2027 deadline. However, some requirements start much sooner. For example, you’ll need to start reporting vulnerabilities in September 2026. EU RED cybersecurity provisions started applying from August 2025. The countdown has already started.
Although these laws have different names and come from different regions, they’re all moving toward the same basic requirements. If your system covers these five areas, you’ll be set for compliance almost everywhere:
Every regulation bans universal defaults. Unique per-device identity is the baseline.
CRA mandates security updates throughout product lifecycle. No OTA = no EU sales after 2027.
Public reporting channels, coordinated disclosure, and defined response timelines.
Data protection in transit (TLS) and at rest (AES-256). No exception.
SBOMs are becoming mandatory. Know what’s in your software and be ready to prove it.
Comprehensive logging of security events for conformity assessment and incident response.
Behind most of these changes is one global standard: ETSI EN 303 645. It’s used everywhere, from the UK and Singapore to Japan, the EU, and the US. If you build your system to meet ETSI’s 13 key requirements, you’ll have a strong baseline for compliance in almost any market.
A common mistake is thinking that if your IoT platform is secure, your whole product is automatically compliant. It’s not that simple.
Security is a shared responsibility across three layers: The platform provides infrastructure. It includes certificate lifecycle management, OTA delivery mechanisms, encrypted communications, access control, and audit trails. These features enable compliance.
The device firmware must correctly integrate those capabilities. It can range from implementing the TLS client, handling certificate installation, validating OTA downloads, executing rollback logic, to forwarding audit events.
The hardware provides the trust anchor. It’s where secure keys are stored, secure booting happens, and tamper protection is enforced.
The OTA example: For instance, with over-the-air (OTA) updates, /IOTCONNECT™ handles secure delivery, staged rollout, scheduling, delta packaging, and audit logging. But firmware validation, installation integrity, rollback logic, and boot verification are device-side responsibilities. The platform enables OTA compliance. The firmware executes it.
If you want CRA or PSTI certification, make sure you know who is responsible for what you want. Otherwise, you might find out you’ve missed something important right in the middle of an expensive certification process.
/IOTCONNECT™ was built with a zero-trust approach and six layers of security. They are from X.509 certificate-based device identity to detailed audit logs. Here are the most important features for meeting compliance:
Certificate-first identity: There are no passwords or shared secrets. Each device gets a unique X.509 certificate with automated lifecycle management (provisioning, rotation, revocation). This single architectural decision addresses the most fundamental requirement across every regulation.
OTA updates as compliance infrastructure: You get staged rollouts, partial (delta) updates, rollback options, scheduling, and full audit trails. This setup lets you deliver security updates to every device in your fleet, as required by regulations like the CRA.
Encryption by default: All data sent is protected with TLS 1.2/1.3 encryption. And everything stored uses AES-256. Your data stays secure from end-to-end.
Built-in audit evidence: Every security event is logged with a timestamp and who did it. This makes it easy to provide proof for compliance reviews like CRA, IEC 62443, or SOC 2, without adding extra tools.
Softweb Solutions maintains ISO 27001 and SOC 2 Type II at the organizational level, with /IOTCONNECT™ covered under that certification scope. The platform is GDPR-aligned and supports customer compliance with EU data protection requirements.
Some regulations, including the CRA’s full compliance deadline (December 2027), CISA’s SBOM requirements, and the EU AI Act’s transparency rules, are not fully enforced yet. But they are already on /IOTCONNECT™’s development roadmap. Each new feature is planned to be ready before the corresponding rule goes into effect.
For example, SBOM ingestion and automated CVE correlation are rolling out 18 months before the CRA’s deadline. Incident reporting tools will be available soon. Transparency features for AI models will launch ahead of the EU AI Act, too.
The goal is simple: customers building on /IOTCONNECT™ today should never face a last-minute compliance scramble.
No matter which platform you use, here are the top priorities for any organization selling connected products:
Get our whitepaper for a complete overview of the regulatory landscape, see how /IOTCONNECT™ maps to all the major compliance frameworks, and learn about the shared responsibility model for platform, firmware, and hardware.
North America
North America