Here is the question I ask every connected device manufacturer I sit down with:
If one device in your deployed fleet was compromised tomorrow morning, how long would it take to revoke just that device, without disrupting the other 49,999?
Most security teams go quiet. Not because they haven’t thought about device security. They have. They’ve passed certifications, survived pen tests, satisfied notified bodies. But containment, targeted, surgical, fleet-safe containment is a different test. And it’s the one that regulators, customers, and incident responders are increasingly asking manufacturers to pass.
Why This Question Exposes the Real Gap
Launch-day security is necessary but not sufficient.
A manufacturer can produce a device with strong cryptography, a secure boot chain, and hardened firmware. They can pass every assessment. And still have no operational answer to the containment question, because containment requires capabilities that don’t get built when you’re focused on shipping. There are three distinct ways manufacturers arrive at the same dead end.
Failure Mode 1: Shared authentication secrets. The Meari Technology incident in May 2026 is a clear example: more than 1.1 million Wi-Fi cameras across 118 countries were found remotely accessible through a single MQTT key extracted from an Android app.1 It wasn’t a sophisticated zero-day. It was the same backend key, the same broker infrastructure, the same credential logic applied across brands, geographies, and customers without isolation between them. The distinction matters: a manufacturer’s public key used to verify firmware updates can legitimately be common across devices. The dangerous pattern is shared secrets, private keys, broker credentials, symmetric keys, or any material whose compromise hands an attacker control of devices he never touched. When the authentication secret is shared, revocation of one is revocation of all. You either take down the fleet, or you take down nothing.
Failure Mode 2: No post-market identity management. The U.S. Department of Justice made the downstream consequence concrete in March 2026 when it disrupted command-and-control infrastructure for the Aisuru, KimWolf, JackSkid, and Mossad IoT botnets, collectively more than three million compromised devices.2 Aisuru alone issued more than 200,000 DDoS attack commands. Those devices were not weapons-grade hardware. They were DVRs, cameras, and routers that couldn’t authenticate, update, or be removed from trusted systems after the fact. Someone else operated them.
Failure Mode 3: The hardware-locked trust anchor. This pattern is less visible than a breach but equally disqualifying. It is at work in at least one well-known appliance OEM, where the root public key and trust anchor hash are programmed into one-time-programmable fuses in the SoC at manufacture, with no authenticated rotation path and no backup trust anchor provisioned alongside. The intermediate CA is pinned in firmware to that root. For a fleet of water heaters, heat pumps, and HVAC controllers with expected service lives of ten to fifteen years, the trust architecture is frozen at the moment the device leaves the factory.
The immediate consequence: if the corresponding signing authority is compromised, there is no certificate operation that contains it. Recovery requires pre-provisioned backup trust that does not exist, a firmware-level trust migration mechanism that was not designed in, or physical remediation of deployed units. The longer-term consequence is compounding. Post-quantum cryptography requirements will arrive within the operational lifetime of devices already in the field. When NIST’s finalized PQC algorithms become the compliance baseline,5 a device whose trust anchor is locked in OTP fuses with no migration path cannot be updated to trust the new chain. Crypto agility requires a trust anchor you can move. An immutable fused anchor is one you cannot.
It is worth being precise about where EU CRA draws the compliance line, because it draws it before the hardware-lock question. Even in architectures where trust material is technically updatable, fleet-wide shared authentication secrets conflict with CRA Regulation 2024/28473 on two independent grounds. Annex I, Part I, (2)(b) requires a “secure by default configuration”; ENISA’s standards mapping interprets this as requiring device authentication credentials that are unique per device, complex and randomly chosen, different for each product.4 Annex I, Part I, (2)(d) requires “protection from unauthorized access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems.” A shared secret that cannot scope revocation below the entire fleet fails that access control standard for each individual device, regardless of whether rotation is technically possible. Updatability removes one problem. The shared-secret architecture retains the compliance exposure.
What Per-Device Identity Actually Means
The phrase “per-device identity” sounds like a PKI configuration detail. It isn’t. It’s an operational architecture decision with consequences that reach from the factory floor to the incident response playbook.
When every device has a unique certificate issued from a rooted PKI, bound to hardware where possible, and managed through automated lifecycle processes, you gain something that shared secrets and hardware-locked roots permanently deny you: the ability to act on one device without acting on all of them.
Revocation without recall. If a device in Region A is compromised, you revoke its certificate. Devices in Regions B through Z continue authenticating normally. The blast radius of the event matches the actual scope of the compromise.
Firmware targeting. If a vulnerability affects firmware version 2.4.1 deployed to a specific product line in one geography, you can query your fleet by certificate attribute, identify the affected units, and push a targeted update, not a fleet-wide push-and-hope.
Partner isolation. If your ODM’s shared infrastructure is compromised, your devices aren’t implicated, because your identity model doesn’t share their roots or their secrets.
Evidence on demand. Every enrollment, renewal, and revocation event is logged with a timestamp. When a regulator, customer, or incident responder asks what happened and when, you have a record. Not a best-effort reconstruction. An audit trail.
Crypto agility over the device lifetime. When the trust anchor lives in a managed PKI with a designed-in rotation path, algorithm transitions SHA-2 to SHA-3, RSA/ECDSA to post-quantum are a certificate operation, not a hardware event. For products with ten-to-fifteen-year service lives, NIST’s finalized PQC algorithms5 will become the compliance baseline before many of those devices leave the field. Designing for that transition at architecture time is the difference between a firmware update and a fleet recall.
The Three Tests of Fleet-Scale Revocation Maturity
I think about revocation maturity in three levels. Most manufacturers are at level one. Very few have reached level three.
Level 1 — Designed but untested. Revocation is in the architecture documents. CRL or OCSP is referenced in the PKI design. But mass revocation has never been exercised in staging. No one knows how long it takes, whether devices check the revocation endpoint reliably, or what breaks when the endpoint is unavailable. In the most constrained variant of Level 1, revocation isn’t merely untested, it’s architecturally impossible. If the trust anchor is immutably fused and the certificate path is pinned with no backup, there is no certificate operation that contains a compromise below the fleet level. Every containment scenario collapses into a firmware dependency or physical remediation before it even begins.
Level 2 — Tested in controlled conditions. The team has run a tabletop or staging test. They know the revocation flow works for N devices under normal network conditions and have rough timing data. But the test covered a small subset of the fleet, used production-like but not production infrastructure, and didn’t reach the edge cases: devices on unreliable networks, devices mid-update, devices in low-power states.
Level 3 — Proven at operational scale. Revocation has been exercised against a meaningful portion of the deployed fleet. The team knows the answer to the containment question in minutes, not estimates. Certificate lifecycle automation handles enrollment, renewal, and revocation without manual intervention per device. The audit trail is exportable without custom tooling. And root rotation, the hardest test, does not require a firmware update or a physical recall.
EU CRA’s 24-hour early-warning reporting requirement3 is effectively a Level 3 mandate in disguise. To report within 24 hours that a vulnerability affects a specific subset of your fleet, you need fleet visibility, SBOM impact analysis, and revocation scoping that only automated identity management provides. An immutably locked PKI chain cannot generate that scoped report because it cannot scope the affected set below the level of the entire fleet.
What Manufacturers Getting This Right Look Like
The manufacturers I see ahead of this curve have made one frame shift in their internal conversation: from “are our devices secure?” to “what happens operationally when one isn’t?”
That shift produces different decisions. They invest in per-device certificate issuance at manufacture because they’ve modeled the cost of a recall. They build certificate renewal automation because they’ve calculated how many devices they’d have to manually service at year three. They provision backup trust anchors and signed trust-store update paths at the factory because they’ve internalized that a single immutable trust anchor is a single operational failure point. And they design crypto agility into their architecture because they’ve done the math on how old their devices will be when post-quantum requirements land.
They’ve also built the vocabulary for these conversations with their customers. When an industrial buyer asks, and they are increasingly asking, for documented evidence of identity controls, signed update delivery, SBOM governance, and postmarket vulnerability response, these manufacturers have a Device Trust Evidence Package ready. Not a slide deck. A documented, auditable, evidence-based answer.
How to Get There
If you’re earlier in this journey, four starting points matter most:
Start with secrets, not just certificates. Per-device certificates are the right architecture, but the more immediate audit is simpler: find every shared private key, broker credential, symmetric OTA key, and API token that crosses device or brand boundaries. Those are your highest-probability single points of fleet compromise. A manufacturer’s public signing key being common across devices is normal and acceptable ETSI EN 303 645 distinguishes device authentication credentials (which must be unique per device) from manufacturer verification keys (which need not be).6 The problem is shared secrets. Inventory them first, then build the roadmap to eliminate them.
Audit your trust anchor architecture before the window closes. If your platform fuses a trust anchor with no backup trust path or signed trust-store migration capability, you are carrying a hardware constraint that grows more expensive with every device shipped. CRA Annex I, Part I, (2)(c)3 requires that vulnerabilities be addressable through security updates. An immutably locked trust anchor cannot satisfy that requirement when the vulnerability is cryptographic. The time to design in a rotation path is before production tooling is finalized, not after a million long-lifetime devices are in the field.
Automate renewal before you need to. The manufacturers who get caught by certificate expiration at scale are almost always the ones who planned to handle it manually. Certificate lifecycle automation is an infrastructure investment that pays for itself the first time you avoid a fleet-wide outage during a mass renewal event.
Test containment before you’re required to demonstrate it. Run a tabletop exercise: one product family, one simulated compromise, the clock running. How long does it take to identify affected devices? How long to revoke? What breaks in the rest of the fleet? The answers tell you exactly where to invest next, and whether your revocation architecture is a real capability or a design document.
The Evidence Standard Is Shifting
The era of “secure by design” as a self-attestation is ending. FDA’s Section 524B7 requires documented postmarket processes. EU CRA mandates per-device authentication credential uniqueness as a baseline conformity requirement and requires reporting evidence within 24 hours of an incident.3 Industrial and infrastructure buyers are moving from feature-led to evidence-led procurement. Platform ecosystems like Matter require attestation at the device level, with proper PAA/PAI/DAC segregation, not shared attestation keys.8
The manufacturers who will lead connected device markets in the next decade aren’t just the ones with the strongest cryptography at launch. They’re the ones who designed for the cryptography they’ll need at year twelve, who built revocation, renewal, and trust anchor rotation as operational capabilities rather than compliance checkboxes, and who can prove they controlled their fleet from ship date through end of life.
The question isn’t whether your devices are secure. It’s whether you can contain one that isn’t, and whether your trust architecture will still be sound when the algorithms your devices were born trusting are no longer trusted by anyone else.
Notes & Sources
Sammy Azdoufal, “Meari IoT Cameras: 1.1M Devices Exposed by Hardcoded MQTT Key,” originally reported by The Verge, May 11, 2026; analysis at devdigest.org. See also PetaPixel coverage: petapixel.com. Azdoufal filed five CVEs with Tod Beardsley of runZero; Meari acknowledged the vulnerability but has not fulfilled GDPR breach notification obligations as of publication.
U.S. Department of Justice, “Authorities disrupt world’s largest IoT DDoS botnets responsible for record breaking attacks targeting victims worldwide,” March 19, 2026. justice.gov. See also: Brian Krebs, “Feds Disrupt IoT Botnets Behind Huge DDoS Attacks,” KrebsOnSecurity, March 19, 2026, krebsonsecurity.com; and The Hacker News, March 20, 2026, thehackernews.com.
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, L 2024/2847, 20 November 2024. Annex I, Part I, points (2)(b) secure by default, (2)(c) security updates, (2)(d) access control, (2)(f) integrity protection; Article 14 for 24-hour reporting obligations. Full text: eur-lex.europa.eu. Annex I annotated: cyber-resilience-act.com.
European Union Agency for Cybersecurity (ENISA), “Cyber Resilience Act Requirements Standards Mapping,” November 2024. Sample sub-requirements for Annex I, Part I, (2)(b): “In case default configurations foresee an initial/default credential, the same should use a complex and randomly chosen password, different for each product.” Keywords listed: “randomised password, unique password.” enisa.europa.eu (PDF).
National Institute of Standards and Technology, Federal Information Processing Standards (FIPS) 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA), finalized August 13, 2024. csrc.nist.gov. These represent the first finalized post-quantum cryptography standards; NIST expects RSA and elliptic-curve algorithms to face deprecation pressure on a 10–15 year horizon as quantum computing capabilities advance.
ETSI EN 303 645 v2.1.1, “Cyber Security for Consumer Internet of Things: Baseline Requirements,” June 2020. Clause 5.1 addresses no universal default passwords, requiring device authentication credentials to be unique per device or user-defined. Manufacturer asymmetric public keys used solely for firmware update verification are not classified as device authentication credentials under this standard and need not be per-device. etsi.org (PDF).
U.S. Food and Drug Administration, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” Guidance for Industry and FDA Staff, September 27, 2023. Implements Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act), added by the Consolidated Appropriations Act, 2023, requiring documented postmarket cybersecurity processes including vulnerability monitoring, patching, and coordinated disclosure. fda.gov.
Connectivity Standards Alliance (CSA), Matter Specification v1.x. Device attestation architecture defines the PAA (Product Attestation Authority), PAI (Product Attestation Intermediate), and DAC (Device Attestation Certificate) chain; each production device must carry a unique DAC. Shared or test attestation private keys violate the attestation trust model. Specification available at csa-iot.org.
Cybersecurity and Infrastructure Security Agency (CISA), “Product Security Bad Practices,” October 2024. Catalogues known-bad development and deployment patterns for connected products, including use of default or shared credentials and absence of secure update mechanisms. cisa.gov.
National Institute of Standards and Technology, IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A), May 2020. Defines baseline device cybersecurity capabilities including device identity, configuration management, and software update as foundational requirements for IoT products. doi.org/10.6028/NIST.IR.8259A.
Tim McAllister is Regional Field CTO at DigiCert, where he leads customer-facing technical strategy for Device Trust, Software Trust, and Post-Quantum Cryptography. He contributes to standards bodies including NIST, SAE EVPKI, Matter, and CharIN.
DigiCert Device Trust Manager, Software Trust Manager, and TrustCore SDK are how manufacturers operationalize fleet-scale identity, lifecycle automation, and revocation at deployed scale — including migration paths for platforms with hardware-constrained trust anchors. To schedule a Fleet Trust Exposure Review, visit digicert.com/device-trust or email device-trust@digicert.com.
#DeviceSecurity #IoTSecurity #DeviceTrust #CyberResilienceAct #CryptoAgility #PostQuantum #SecureByDesign #ConnectedDevices