CSA's Product Security 1.1 Expands IoT Certification Beyond Devices to Full Systems
Connectivity Standards Alliance shifts security certification from individual IoT devices to complete systems, including apps and gateways, in response to fragmented global regulations.
CSA moves security assurance upstream to system integrators
The Connectivity Standards Alliance announced Product Security 1.1 at its June 17 Unify event in Davis, California, expanding its certification program beyond individual devices to cover complete IoT systems — apps, gateways, and remote processes included. The change matters because it reframes security accountability from device manufacturers alone to the entire vendor stack, and gives enterprise buyers a single certification to reference across increasingly divergent national IoT security regimes.
CSA describes the update as a response to "the growing complexity of global IoT cybersecurity requirements" and "increasingly fragmented regulatory landscapes." The practical effect: enterprises deploying smart building systems, industrial sensors, or fleet management platforms can now demand system-level certification in RFPs, not just endpoint compliance claims. That shifts the burden of proof to solution providers and system integrators, who must now demonstrate security controls across their entire stack to earn the Product Security 1.1 mark.
What changed from device-only certification
Product Security 1.1 introduces "new levels of security assurance through independent testing pathways," according to CSA's announcement. The prior version focused on device properties — encryption at rest, secure boot, vulnerability disclosure processes. The 1.1 spec expands scope to include how those devices interact with cloud backends, mobile apps, and edge gateways in production deployments.
This addresses a gap in existing IoT security frameworks. EU cybersecurity requirements and national secure-by-design initiatives typically regulate devices in isolation. They define what a sensor or actuator must do when it ships. They say little about what happens when that device talks to a third-party analytics platform or a contractor's mobile app. Product Security 1.1 covers that entire chain, making it a more realistic proxy for operational risk than device-only labels.
For buyers, this means one certification artifact can satisfy auditors asking about endpoint security, application security, and data-in-transit controls simultaneously. That compresses the evidence-gathering process for compliance audits and reduces reliance on vendor self-attestations, which vary widely in rigor.
Procurement and vendor selection impact
The immediate change is in RFP language. Enterprises can now specify "Product Security 1.1 certification at the system level" as a requirement, not a nice-to-have. That disqualifies vendors who ship certified devices but integrate them with uncertified cloud platforms or unaudited mobile apps. It also favors vertically integrated providers — or integrators willing to submit their full stack for third-party testing — over loosely coupled ecosystems of best-of-breed components.
This has budget implications. System-level certification costs more than device-level certification because the attack surface is larger and testing must cover integration points, not just isolated components. Vendors will pass that cost to buyers, either in higher unit prices or in professional-services fees for certification consulting. The tradeoff: reduced post-deployment security incidents and faster passage through procurement and legal review, especially in regulated industries like healthcare and utilities.
The shift also changes the risk calculus for multi-vendor IoT deployments. If a buyer assembles a smart building system from five different vendors — lighting from one, HVAC from another, access control from a third — who owns Product Security 1.1 certification for the integrated system? The building automation contractor, the managed-services provider, or the buyer's internal IT team? CSA's spec pushes that responsibility toward whoever operates the system as a coherent whole, which is often the system integrator or managed-services provider. Buyers should clarify certification ownership in contracts before deployment.
Competitive positioning against national and vendor-specific schemes
Product Security 1.1 competes with vendor-specific trust labels from large cloud providers and device OEMs, and with emerging national IoT security labels in the EU and other jurisdictions. CSA's advantage is cross-vendor neutrality: one certification that works across Apple, Google, Amazon, and Samsung ecosystems, rather than separate audits for each. That matters in enterprises with heterogeneous IoT estates, where standardizing on a single vendor ecosystem is often politically or technically infeasible.
The risk is low uptake. If major IoT platform vendors continue to promote their own security certifications and buyers see Product Security 1.1 as optional, it becomes another checkbox in a sea of checkboxes rather than a de facto procurement standard. CSA's success depends on whether large enterprise buyers — healthcare systems, smart-city operators, industrial facility managers — write it into RFPs consistently enough to make vendor adoption mandatory.
What to watch
Track how quickly system integrators and managed-services providers adopt Product Security 1.1 certification. If major building automation contractors and industrial IoT integrators submit their platforms for third-party testing in the next 12 months, that signals the standard has traction. If adoption stalls at device manufacturers and does not extend upstream to solution providers, the system-level promise remains theoretical.
For buyers planning IoT deployments in 2026 and 2027, the decision point is whether to require Product Security 1.1 now or wait for broader vendor adoption. Requiring it today narrows the vendor pool and may increase costs. Waiting risks deploying systems that fail to meet future regulatory baselines or require costly retrofits when certification becomes table stakes. The safer path: write Product Security 1.1 into RFPs for new deployments and phase it in as a hard requirement over 18 months, giving vendors time to certify while signaling clear procurement intent.
Technology decisions, clearly explained.
Weekly analysis of the tools, platforms, and strategies that matter to B2B technology buyers. No fluff, no vendor spin.
