Integrated Security Manager (iSM)

Security and lifecycle control built into the Embedded Microservice Runtime

The integrated Security Manager is the security and lifecycle layer of the Embedded Microservice Runtime. It provides a consistent set of security services, policy enforcement, and in-field controls, so you can deploy and operate isolated microservices on embedded devices without pushing security requirements onto each product team or developer.

integrated Security Manager (iSM) operates at three levels on an embedded device.

Edge to Cloud Secure Supply-Chain Management, which is responsible for an edge device, is fully aligned with vendor credentials, in-field security lifecycle management, and approved SBOM and vulnerability reporting.
Device Protection: it works like an isolated, protected “Trusted Execution Environment” that protects the entire device's assets. It handles and hides all security (e.g., PSA, SESIP) and Legislation (EU CRA, UK, US, ETSI), such as device secure boot, secure updates with rollback protection, secure storage, attestation, unique ID, crypto services, etc.
Microservice Protection: iSM treats each Microservice as an independent virtual environment/machine and extends Device Protection mechanisms to each Microservice individually, including secure boot, upgrades, storage, and attestation. Each Microservice has its own security lifecycle. Microservices are protected in a platform-agnostic way, and iSM handles and hides the architectural security mechanisms, providing the same level of security across secure (ARM TrustZone, CHERI) and non-secure (Legacy ARMv7/ARMv6-M) architectures.

1. Edge to Cloud Supply Chain and Fleet Management

Microservice Store is a de facto supply chain solution that connects businesses and even securely integrates third-party Microservices into a product. Integrated Secure Manager (iSM) enables this on edge devices. It uses highly maintained/highest security standards and mechanisms. It prevents product vendors to invest and maintaining their supply chain solutions.

1.1. In-Field Security Lifecycle: iSM enables product vendors to perform in-field provisioning and inject their root certificates and keys to authenticate entities from the Microservice Store throughout the device lifecycle. It also handles “factory reset” and “decommissioning” of the device.

1.2. Automated Microservice Upgrades: Automatic SW Upgrades are mandatory by the security legislation, and Microservice Store sends the individual upgrades/OTA packages for only Microservices that are not using the latest version.

1.3. Software Bill of Materials (SBOM): Instead of a single monolithic traditional embedded software that mixes all software modules into a chaotic image, embedded Microservices are independent binaries with different identifications such as Unique ID, Name, Version, Access Rights and Certifications, and so Hash.iSM generates a PSA Entity Attestation Token(EAT) that includes the mentioned details of each Microservice. Legislation such as the EU CRA requires product vendors to share their SBOMs, and Microservice Store can share the SBOM with the EU CRA if the vendor allows it. For markets where SBOM sharing is not mandatory, the vendor can still share the SBOM publicly through the Microservice Store.

1.4. Vulnerability Reporting and Mandatory Action

Microservices are isolated, access-controlled executables, and, in the event of a violation, iSM reports the vulnerability to the Microservice Store and sends notifications to the product vendor and the developer (if the Microservice is developed by a third-party vendor/developer), including the violation details. The developer can use the violation/crash details to debug the Microservices. Here, the developer must provide a fix within a finite period; otherwise, they are banned from the Microservice Store.

Vulnerability Reporting is required by Legislation such as the EU CRA, and Microservice Store reports vulnerabilities to the EU CRA if the product vendor enables it.

2. Device Protection (a Software TEE/Security Monitor)

iSM provides “Functional Security” that protects all entities on the device. At its core, it provides all the security mechanisms of Platform Security Architecture (PSA) and SESIP, as well as legislative requirements.

It is a software module that provides unified security across legacy non-secure architectures such as Armv6-m (Cortex-M0) and ARMv7-m (Cortex-M3/M4/M7), as well as RISC-V MCUs, and also works on secure architectures such as TrustZone and CHERI.

3. Microservice Protection: Microservices as Independent Secure Virtual Machines

iSM treats each Microservice as an independent virtual environment/machine and expands Device Protection mechanisms to each Microservice individually.

Secure Boot: Each microservice is authenticated individually during device startup.
Secure Upgrade: Each Microservice can be upgraded individually and securely.
Anti-Rollback: Each Microservice has a monotonically increasing version that allows explicit downgrades and upgrades.
Isolation: Each Microservice is isolated from the others by the integrated Hypervisor in Microservice Runtime.
Security Lifecycle: Each Microservice has its own lifecycle, apart from the device security lifecycle.
Unique Identification: Each Microservice has its own unique ID.
Attestation: Each Microservice is part of the Entity Attestation Token(EAT), and has its own attestation.
Secure Storage: Each Microservice has its own isolated storage.
Interaction: Each Microservice has a secure interface to interact with the others.
Crypto Services: Each Microservice can have different access, Keys and API using the Microservice Access Policy.

The above features are generic requirements of the security certification, but iSM also offers a platform-agnostic approach to access control, called Microservice Access Policy.

3.1. Microservice Access Policy

Microservice Access Policy is a platform-agnostic way to control access to resources, such as HW Peripherals, SW Operations, or Memories.

By default, A Microservice cannot access any resource; the product must explicitly assign a resource/entity to a Microservice to give access. iSM achieves this in a platform-agnostic way; it handles and hides the architectural (TrustZone, CHERI, Non-Secure) security mechanisms and provides a “unified Security and Access” for Microservices. In this way, once a Microservice Developer defines the required “Logical” resources, iSM provides the resources, regardless of the CPU architecture.

Microservice Access policy is cryptographically protected against unauthorised modifications; signed, encrypted, rollback protected.

Summary:

Integrated Security Manager (iSM), built into the Embedded Microservice Runtime, is a proactive security and lifecycle framework that delivers consistent protection across secure and non-secure hardware architectures. It centralises, enforces, and automates core security requirements, including identity, secure boot, policy-based access control, secure update, attestation, and in-field lifecycle operations, so security is handled by the runtime rather than by each product team.

For product vendors and microservice developers, who effectively operate as virtual device and service providers within the platform, iSM removes the burden of assembling and maintaining complex security stacks. It contains faults and violations in real time, preserves system availability, and supports compliance-oriented evidence and reporting, reducing engineering overhead while improving time-to-market, cost efficiency, and brand trust.

This is the era of normalising security, not only for security-critical systems, but for every connected device. Security and safety should be standard expectations, not premium features.

👉 Try Now!
"Build a Secure IoT Device In Seconds"

All you need is your web browser!