Cybersecurity legislation · Global perspective
Cybersecurity obligations vary across markets, products and operating environments. RIoT Secure gives product builders and system integrators a lifecycle foundation: device identity, protected communication, software maintenance and operational visibility that can become part of a larger security architecture.
The role of the foundation
A connected product combines hardware, application software, backend services, people and operational processes. RIoT Secure contributes the device communication and lifecycle layer within that system. Its value is to make selected security controls practical to integrate, maintain and use throughout a device’s working life.
Product and system compliance depends on the applicable requirements, the implementation and the responsibilities of each organisation involved. Using the platform supports that engineering work; it does not by itself establish conformity, certification or compliance.
Lifecycle capabilities
Across different regulatory settings, teams repeatedly need dependable ways to identify devices, protect communication, maintain software and understand what happened. These are engineering building blocks to integrate and validate within your product’s own threat model and operating environment.
Define trust boundaries and responsibilities early. Fusion separates application execution from the communication and security engine on dedicated microcontrollers, helping keep application resources focused while the lifecycle layer handles its own work.
This separation gives the wider architecture a clear boundary to build around. Product teams still assess interfaces, permissions, failure modes and the security of their complete design.
A hardware root of trust can anchor device identity and cryptographic operations when supported by the selected hardware and provisioning configuration. A secure element can help protect key material and bind a device to its lifecycle identity.
Agree the trust chain, credential ownership, provisioning and revocation model for the deployment. Hardware-backed trust and boot protection must be selected and validated for the target; they are not universal properties of every configuration.
µTLS provides encrypted communication between the device and the RIoT Secure backend over the selected network transport. It adds a device communication security layer alongside the customer’s existing network controls.
The integration gateway translates the compact device data into formats used by downstream platforms. Authentication, authorisation, key lifecycle and protection of those downstream services remain part of the full solution design.
Oasis brings firmware delivery and software version management into the device lifecycle. Teams can coordinate updates across deployed fleets through the management console or REST API, including from their existing operational tools.
The target integration must define and validate update authorisation, authenticity and integrity checks, installation behaviour and support commitments. Secure delivery needs a trusted installation path as well as protected communication.
Rollback support provides a path back to an approved, known-good software version when a deployment needs recovery. This helps teams plan for update failures and operational continuity as part of their maintenance model.
Availability depends on the selected hardware, bootloader and storage configuration. Define which versions remain approved, validate the recovery path and control downgrades so that recovery does not reintroduce a known vulnerability.
Device identity, software versions and lifecycle-operation outcomes provide inputs to product and fleet traceability. Integrate the available Oasis records and REST API operations into your monitoring, support and incident-response workflows.
Agree event coverage, timestamps, access controls, retention and evidence handling for the deployment. Lifecycle visibility contributes to the wider evidence trail; its completeness and protection depend on how the surrounding system is implemented and operated.
Product, system & organisational context
The product or system team connects these capabilities to its own risk assessment, application security, backend controls, testing and operating procedures. Update and recovery behaviour need validation on the actual hardware, including fault conditions and the consequences of a failed change.
The responsible organisations also establish the surrounding processes: vulnerability intake and disclosure, software supply-chain information, support periods, incident handling, technical documentation, evidence retention and any required assessments or declarations. Lifecycle operations can support those processes, but the processes must be designed and operated.
Responsibilities follow each party’s legal role. Manufacturers, component providers, suppliers and operators can each have duties. The CRA, for example, can cover components as well as finished products. Integrating RIoT Secure does not transfer or settle those obligations; scope and responsibilities need assessment across the relevant supply chain.
Selected legislation around the world
Product legislation, organisational cybersecurity duties and procurement requirements address different scopes. The examples below show why a global product strategy needs more than a single-regulation checklist.
This is a selected orientation for requirements scoping. Check the primary sources for current scope, exclusions, national implementation and applicable duties.
Product cybersecurity. The Cyber Resilience Act addresses the security of in-scope products with digital elements throughout their lifecycle, including relevant components. Risk assessment, secure design, vulnerability handling and support are part of the manufacturer’s wider obligations.
Manufacturer reporting obligations began on 11 September 2026; the main requirements apply from 11 December 2027. Device lifecycle controls contribute to the implementation, alongside the product’s documentation and conformity-assessment work.
Organisational cybersecurity. NIS2 addresses risk management and significant-incident reporting for in-scope entities across covered sectors, through national implementing legislation. Supply-chain security and management accountability are part of that wider context.
Device maintenance, inventory and lifecycle visibility can support an operator’s measures. They sit within the organisation’s governance, continuity, incident-response and reporting arrangements; NIS2 is not a certification for an individual IoT component.
Consumer connectable products. The UK product-security regime has applied since 29 April 2024. Its baseline requirements cover passwords, a published route for reporting security issues and published minimum security-update periods, with additional duties for the relevant supply-chain roles.
Technical capabilities and manufacturer processes need to work together. Assess whether the product is in scope rather than treating the regime as a universal requirement for every industrial deployment.
Consumer-grade smart devices. Under the Cyber Security Act 2024 and the Security Standards for Smart Devices Rules 2025, in-scope devices manufactured from 4 March 2026 must meet requirements concerning passwords, security-issue reporting and published support periods.
The rules focus on devices intended for personal, domestic or household use and include exclusions. Product purpose, manufacture date and the manufacturer’s or supplier’s role matter when determining applicability.
Federal systems and procurement. The IoT Cybersecurity Improvement Act of 2020 addresses IoT devices owned or controlled by the federal government. NIST SP 800-213 supports agencies in identifying device requirements within their wider system risk-management process.
This is a federal-government context, not a single compliance regime for all commercial IoT. State, sector and contractual requirements need their own review for the intended market and customer.
Critical systems and regulated entities. Singapore’s Cybersecurity Act establishes cybersecurity oversight, including duties for designated Critical Information Infrastructure. Key amended provisions came into force on 31 October 2025, including changes concerning CII and Systems of Temporary Cybersecurity Concern.
The relevant context is the designated system or entity and its operating obligations. Device lifecycle infrastructure can contribute to that environment’s controls and visibility as part of the wider operational architecture.
Standards, guidance & assurance schemes
Standards and guidance help teams specify and assess technical capabilities. NIST IR 8259A describes a core device cybersecurity baseline; ETSI EN 303 645 addresses consumer IoT security; and the IEC 62443 series addresses industrial automation and control-system security. Their scopes and assessment routes differ.
Assurance schemes add another layer. Japan’s JC-STAR, for example, assesses IoT products against defined security requirements and provides conformance labels. Participation, procurement conditions and assessment scope need separate consideration. Referencing these materials does not imply that RIoT Secure or a customer’s finished product holds a certification or label.
Build on a solid foundation
Bring your target hardware, markets and operational requirements. We can discuss the lifecycle architecture, the controls available in the selected configuration and how they connect to your product’s existing interfaces and processes.