An IoT device management platform can enrol, command and reflash every device in a fleet, so whoever controls it can push rogue firmware, send commands to physical equipment or brick thousands of devices at once. The platform is the cloud or on-premises back end that registers devices, issues or trusts their credentials, brokers their messages, stores their state and telemetry, and runs fleet-wide jobs such as over-the-air (OTA) updates. ETSI EN 303 645 calls these "associated services" and expects them to be secured as part of the product. This guide is for IoT platform engineers, product security teams and OT and facilities security leads who run such a platform. It covers admin roles, the platform's own service identities and keys, device enrolment trust, fleet job guardrails, data and logs, hardening and lifecycle. It does not repeat device-side identity or firmware signing, which are in the Identity for IoT Fleets Guide and the IoT Secure Firmware Update Guide (SUIT, signed OTA). It is vendor-neutral: confirm the exact setting names in your vendor's documentation.
Key takeaways
- The platform is the root of trust for the fleet. Its enrolment authority, signing keys and job engine decide what every device trusts and runs, so manage it as tier 0 for those devices.
- Separate enrolment, operations and firmware release. The people and identities that register devices, send commands and release firmware should be different, with approval for fleet-wide actions.
- Kill shared and hard-coded credentials. Per-device credentials, as ETSI EN 303 645 provision 5.4-4 requires for associated services, and no API keys baked into firmware (5.4-3).
- Cap the blast radius of jobs. Staged rollouts, target limits, abort thresholds and a kill switch stop a bad update or stolen account reaching every device.
- Keep the platform's audit log elsewhere. Enrolment changes, policy edits, job creation and key operations belong in a store platform admins cannot alter.
Why the platform is the fleet's root of trust
The NCSC describes tier 0 as the root of trust that other administration depends on, and warns against the "browse up" anti-pattern of administering a higher tier from a lower-tier system. For a device fleet, the management platform is that root: compromise it and you control the devices, regardless of how well each device is built. ETSI EN 303 645 V3.1.3 (September 2024) defines associated services as digital services that, together with the device, are part of the overall consumer IoT product and are typically required for its intended functionality, such as companion apps or cloud back ends, and its provisions on credentials, secure communication, telemetry and user data deletion apply to them.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Console and tenant settings | Users, roles, device groups, policies, integrations | Adds admins, widens policies, disables logging | SSO with phishing-resistant MFA, few admins, trusted admin devices |
| Enrolment and provisioning service | Trusted CAs, enrolment groups, claim or bootstrap credentials | Registers rogue devices or impersonates real ones | Per-device identity, protected CA keys, approval for new enrolment trust |
| Message broker and topic policies | Which device can publish or subscribe to which topics | Reads or injects telemetry and commands across devices | Per-device topic scoping, deny by default |
| Command, job and OTA engine | Remote commands, configuration pushes, firmware rollouts | Fleet-wide malicious update or command (T1072) | Staged rollout, approval, target caps, signed firmware |
| Device state store (shadows or twins) | Desired and reported configuration | Sets dangerous desired state that devices apply | Write access limited to approved services, validation on the device |
| Telemetry and data store | Sensor data, location, personal data | Data theft or manipulation (T1565) | Encryption, access by data class, retention |
| Integrations (analytics, ERP, ticketing, apps) | Service credentials and API keys | Indirect control through a weaker system | Per-integration identity, least privilege, rotation |
Admin roles and console access
- Role design: separate at least: platform administrator (tenant settings, roles, integrations), enrolment administrator (CAs, enrolment groups, device registration), operator (monitor, run approved commands on scoped device groups), firmware release manager (approve and launch OTA jobs) and read-only analyst. Deleting devices, changing broker policies and changing enrolment trust are high-impact rights.
- Scope by fleet: limit operators to the device groups, sites or product lines they support, so a regional account cannot command the global fleet.
- Authentication: SSO with phishing-resistant MFA for all console users and one tested break-glass account. The CISA and FBI Secure by Demand guide suggests asking whether SSO is offered at no additional cost and whether MFA or passkeys are on by default. See the Break-Glass Account Guide.
- Admin devices: follow the NCSC principle of gaining trust in management devices; administer from privileged access workstations, not from engineering laptops used for device debugging. See the Privileged Access Workstations Guide.
- Field and partner access: installers and maintenance partners often need temporary enrolment or diagnostic rights. Give them named, time-bound accounts scoped to their sites, never shared logins. See the Third-Party Access Guide.
- Review: review roles and scopes every quarter (our recommendation) and on every leaver or partner change.
Device enrolment trust
Whatever the platform trusts at enrolment, it will accept as a real device. This is where most fleet-wide compromises start.
- Per-device credentials: ETSI EN 303 645 provision 5.4-4 requires that credentials protecting communication with associated services are unique per device, and 5.4-3 prohibits hard-coded critical security parameters in device software source code; the standard's explanatory text notes these can include API keys for security-sensitive functions in a remote service. Use per-device certificates or keys, ideally generated in hardware. See the IoT Device Identity with TPM and DICE Guide.
- Protect the issuing CA: a CA that the platform trusts for enrolment can mint devices. Keep its private key in an HSM or managed key service outside the platform admins' control, and require two approvers to add a new trusted CA or enrolment group. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
- Bootstrap and claim credentials: if devices enrol with a shared claim certificate or token at the factory, scope it to enrolment only, rate limit its use, rotate it per production batch and alert on use outside expected volumes (our recommendation).
- Allow lists: where volumes allow, pre-register expected device identifiers from manufacturing records so unknown devices are rejected.
- Revocation: test that revoking a device certificate or disabling a registration takes effect on the broker within minutes, not at the next certificate expiry.
Provisioning flows and onboarding protocols are covered in the IoT Device Onboarding Guide.
Service identities and keys the platform uses
| Identity | Needs | Avoid | Pattern |
|---|---|---|---|
| Back-end services sending commands | Invoke commands or update desired state for scoped device groups | Tenant-wide owner policies or shared access keys used by many services | Workload identity with role scoped to device groups and operations |
| Data pipeline and analytics | Read telemetry streams | Rights to write device state or create jobs | Read-only identity per pipeline |
| Firmware build and signing | Sign firmware images and upload to the OTA store | Signing keys stored in the platform or the build server file system | HSM-backed signing in a separate account, release through approval |
| Mobile and companion apps | Act for one user on that user's devices | Embedded platform API keys with fleet-wide scope | User-delegated tokens checked against device ownership |
| Integrations (ticketing, ERP, partner APIs) | Narrow read or write for a business process | Administrator API keys with no expiry | Per-integration keys with owner, expiry and network restriction |
- No fleet keys in apps: a platform key embedded in a mobile app or device image will be extracted. Use per-user and per-device credentials and enforce ownership on the server.
- Rotate and expire: rotate any remaining static keys at least every 90 days (our recommendation) and store them in a secrets manager. ETSI provision 5.5-8 expects secure management of critical security parameters across their whole lifecycle. See the Secrets Management Guide.
- Inventory them: record every platform identity with owner and scope in your NHI inventory. See the Device and IoT Identity Guide.
Fleet job and OTA guardrails
- Staged rollout: every firmware or configuration job starts with a canary group, then expands in waves with automatic abort if failure or disconnect rates exceed a threshold, for example 2 per cent (our suggested starting point).
- Approval and caps: require a second approver for jobs targeting more than a set share of the fleet or any safety-relevant device group.
- Signed content only: the platform should only distribute signed firmware and devices should verify signatures before installing (ETSI 5.7 Ensure software integrity). The platform holding the update is not the same as the platform holding the signing key.
- Destructive commands: factory reset, decommission, disable and remote unlock commands need approval and logging of who, what and which devices.
- Kill switch: document how to cancel all running jobs and freeze new ones, and test it twice a year (our recommendation).
- Resilience: devices should keep operating safely if the platform is unreachable (ETSI 5.9 Make systems resilient to outages), so an outage or a deliberate takedown does not stop physical operations.
Data, telemetry and the platform's own logs
ETSI provision 5.10-1 expects telemetry to be examined for security anomalies, and 5.11-2 expects users to be able to delete their personal data from associated services. Both need the platform's data store to be managed deliberately.
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role, SSO or user change | Persistence in the console | Always |
| New trusted CA, enrolment group or claim credential | Rogue device enrolment | Always |
| Broker or device policy widened | Cross-device data access or command injection | Always |
| Job or OTA created, approved or expanded | Fleet-wide execution (T1072) | Above target cap or outside change windows |
| Spike in enrolments, connection failures or devices offline | Cloning, credential misuse or a bad update | Above baseline |
| Service key created or used from a new location | Added credentials (T1098.001) | Always |
| Bulk telemetry export or data deletion | Data theft or evidence loss | Above baseline |
- Export it: stream the audit log to a SIEM the platform's admins cannot alter. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system and AC-6(9) covers logging privileged functions. Secure by Demand asks SaaS providers to keep security logs for at least six months at no additional charge.
- Protect telemetry: encrypt at rest, separate personal data such as location from operational data, and set retention by data class (ETSI 5.8 Ensure that personal data is secure).
- Duplicate identities: the same device identity connecting from two places at once is a strong sign of cloning; alert on it.
Hardening and lifecycle
- Network: expose only the device endpoints and the console; keep data stores and internal APIs private. Require TLS with modern cipher suites for device connections (ETSI 5.5 Communicate securely).
- Patch the platform: for self-hosted platforms and brokers, apply vendor security updates promptly and subscribe to the vendor's security advisories page. ETSI provision 5.2-3 expects manufacturers to monitor and fix vulnerabilities in the associated services they operate.
- Disable what you do not use: remote shell, port forwarding and debug tunnelling features should be off unless a documented use case needs them (CM-7).
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions; confirm per-device credential support, CA key custody options, role and device-group scoping, job approval features, audit log export and data residency. See the IoT Security Buyer's Guide. |
| Deploy | Enable SSO first; set up the enrolment CA outside the platform; define device groups and roles before onboarding; deny-by-default broker policies; audit export on day one. |
| Run | Quarterly review of roles, enrolment trust, broker policies and service keys; kill switch test; canary results reviewed for each release. |
| Respond | If the platform or an admin account is suspected compromised: freeze jobs, review enrolment and policy changes since the first suspicious event, rotate service keys, revoke suspect device identities and check devices for unapproved firmware. |
| Retire | Migrate or decommission devices, revoke device credentials and enrolment trust, delete service identities and keys, obtain written confirmation of data deletion (MP-6), and export the audit history you must keep. |
Roll back a hardening change, such as tightening a broker policy, by keeping the previous policy versioned and restoring only the specific topic permission a device class needs, never a wildcard.
Detection and measurement
- Percentage of devices with unique, per-device credentials (target: 100 per cent for new devices).
- Number of administrators who can launch fleet-wide jobs (target: five or fewer, our suggestion).
- Percentage of OTA jobs run with a canary stage and second approver.
- Service keys past rotation date (target: zero).
- Time from device revocation to broker rejection, measured in tests.
- Days of platform audit log available in the SIEM.
Framework mapping
| Control area | ETSI EN 303 645 | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat addressed |
|---|---|---|---|---|
| Console roles and scopes | No direct provision | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Device credentials and enrolment | 5.4-3, 5.4-4, 5.5-8 | IA-3, IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials |
| Fleet jobs and firmware | 5.3, 5.7 | CM-3, SI-7, CM-14 | PR.PS-02 | T1072 Software Deployment Tools, T1195.002 Compromise Software Supply Chain |
| Telemetry and personal data | 5.8, 5.10-1, 5.11-2 | SC-28, AU-11 | PR.DS-01 | T1565 Data Manipulation |
| Audit log protection | No direct provision | AU-9(2), AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
Common failure patterns
- One credential for the whole fleet: a shared key in the firmware image lets anyone who extracts it impersonate any device.
- Enrolment CA key inside the platform: a platform admin, or an attacker with that role, can mint unlimited trusted devices.
- Wildcard broker policies: every device can subscribe to every topic, so one compromised device reads the fleet's commands and data.
- OTA straight to 100 per cent: a faulty or malicious image reaches every device before anyone notices.
- Fleet keys in the companion app: an administrator key shipped in a mobile app gives control of other customers' devices.
- Audit trail left inside the platform: enrolment and job history exists only in the console an attacker controls.
Practitioner checklist
- Treat the platform, its enrolment CA and its job engine as tier 0 for the fleet.
- Enforce SSO with phishing-resistant MFA and separate platform, enrolment, operator and firmware release roles scoped by device group.
- Issue unique per-device credentials and remove any hard-coded or shared keys from firmware and apps.
- Keep the enrolment CA and firmware signing keys in HSM-backed stores outside the platform, with two-person approval for changes.
- Apply deny-by-default broker and device policies scoped to each device's own topics and state.
- Require canary stages, abort thresholds, approval caps and a tested kill switch for fleet jobs.
- Give back-end services and integrations scoped workload identities and rotate any static keys.
- Export the platform's audit log to a store its admins cannot change and alert on enrolment, policy and job changes.
- Review roles, enrolment trust, policies and keys every quarter, and keep a decommissioning checklist.
Standards and references
- ETSI: EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things: Baseline Requirements
- NCSC: Risk manage administration using tiers
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1072 Software Deployment Tools
Related NHI Mgmt Group resources: IoT Security Guide · Identity for IoT Fleets Guide · Enterprise IoT Security Programme Guide · ETSI EN 303 645 Consumer IoT Guide · Securing the identity threat detection and response (ITDR) tool itself