Article / IoT Certification
Certifying IoT products across Japan, Korea, and Singapore in 2026
The mutual recognition map and where it quietly breaks.
If you are responsible for security on a connected product expanding into Asia-Pacific in 2026, you are probably already being pulled across certification schemes. A Japanese partner asks about JC-STAR readiness. A Korean distributor asks about KISA CIC. A Singaporean enterprise lead mentions CLS. Meanwhile, German prospects want the BSI IT Security Label, and leadership wants a simple cost answer.
The good news is that the regional certification landscape has consolidated. A single certification can carry you into multiple markets. The harder part is that mutual recognition is conditional, and the places where it does not translate are exactly where vendors lose time and budget.
Core argument
The labels are converging. The evidence formats are not.
The teams that win are the ones that treat security evidence as a reusable, structured asset instead of a one-off report per jurisdiction.
Current map
The Current MRA Landscape
Formal Mutual Recognition Arrangements now connect most of the major consumer IoT cybersecurity labels. Because these schemes share the same technical DNA, especially ETSI EN 303 645, certifying once and getting recognized in multiple jurisdictions is becoming a practical strategy.
Singapore CLS
The broadest reciprocity web for consumer IoT today.
- Finland Cybersecurity Label: CLS Level 3+
- Germany BSI IT Security Label: CLS Level 2+
- Korea KISA CIC Basic+: CLS Level 3
- UK PSTI: recognized baseline alignment
- Japan JC-STAR: expected reciprocal recognition in June 2026
Korea KISA CIC
Useful when Korea is already a priority market and lab testing is expected.
- Singapore CLS Level 3: CIC Basic+
- Germany BSI Smart Consumer Devices: CIC Basic and Standard
Japan JC-STAR
A practical baseline for Japan, with procurement-oriented higher tiers.
- UK PSTI statutory requirements: JC-STAR Level 1
- Singapore CLS: expected reciprocal recognition in June 2026
- US and EU: active alignment discussions
The catch
Why it will not auto-translate
The MRAs are real, but they do not make certification work disappear. If it feels like the same testing is being repackaged for five schemes, that is usually because the label mapping is easier than the evidence mapping.
MRAs are not blanket passes
Reciprocity is specific to the tier, scheme, and mapping. Korea and Singapore recognize each other in defined bands, but KISA CIC Lite does not automatically produce a Singapore CLS label, and CLS Level 4 still requires Singapore-specific evaluation.
They cover specific product categories
Most arrangements focus on smart consumer devices: cameras, speakers, home automation hubs, health trackers, appliances, and adjacent products. Gateways, industrial sensors, and medical-adjacent devices can sit at the edge of the category definition.
They cover the label, not the evidence
A receiving jurisdiction usually still wants the original certification documentation, local application materials, and sometimes additional evidence in its own format. The MRA reduces work; it does not remove the submission.
High tiers still need local labs
JC-STAR STAR-3 and STAR-4, KISA CIC, and Singapore CLS Levels 3 and 4 all preserve local evaluation requirements in important places. Higher-tier procurement reach still has to be planned as real certification work.
Under the labels
The controls converge, but the evidence diverges
Most schemes are asking for substantially overlapping controls. The gap is in how each scheme wants proof captured, formatted, reviewed, and submitted.
Convergence
The security baseline is becoming common.
- No universal default passwords
- Vulnerability disclosure mechanism
- Defined security update period
- Secure communication of sensitive data
- Secure storage and secure update mechanisms
- Attack-surface minimization
- Secure-by-default configuration
Divergence
The submission format still changes by market.
- Singapore CLS wants declarations of conformity backed by supporting evidence, with binary analysis at Level 3 and pentesting at Level 4.
- JC-STAR STAR-1 uses self-declaration against a checklist, while STAR-3 and STAR-4 require formal evaluation reports from designated assessors.
- KISA CIC wants third-party lab reports at every level, structured to KISA's procedural format.
- Germany's BSI label wants manufacturer declarations against applicable standards, with additional detail for higher product categories.
This is the gap between "the controls are the same" and "the evidence is the same."
The MRAs close part of the first gap. The second gap is yours to handle.
Planning
How to plan your certification strategy
The right starting point depends on which markets matter first, which tier you need, and whether the product clearly fits the covered category. Plan the roadmap before the first application, because the first evidence model will shape every later submission.
Optimize for reach versus investment
If you need a first anchor, Singapore CLS Level 3 is often the highest-leverage starting point for consumer IoT because it maps into multiple markets. JC-STAR Level 1 can be the lighter baseline when Japan and the UK are the near-term focus.
Plan ahead for local evaluations
Treat MRAs as discounts, not free passes. For government, critical infrastructure, and serious enterprise procurement, assume that a higher-tier local lab evaluation may still sit on the roadmap.
Make evidence reusable before submissions multiply
A separate evidence pack for every jurisdiction turns certification into a repeated reformatting exercise. The durable asset is not the label; it is the structured evidence behind the label.
Hidden cost
The evidence format problem
If you produce a separate evidence pack for each submission, you are paying repeatedly for work that should compound. The solution is not a magic template. It is a structured internal evidence asset that can be projected into each receiving scheme.
The real cost of multi-market IoT certification is not only the label. It is the structure behind the label.
If your security work produces an unstructured pentest report and a checklist spreadsheet, every new market means manual translation into the receiving lab's preferred format. You do that again for product variants, scheme changes, and every new reciprocity path you want to use.
The better approach is to build the evidence once in a form that preserves the product model, the security claims, and the validation trail.
Structured evidence should capture
- Product components, actors, roles, and trust boundaries
- Interactions, data flows, update paths, and operational workflows
- Security properties the product claims to preserve
- Validation records that connect test evidence to each property
- Projection-ready views for JC-STAR, KISA CIC, CLS, BSI, and PSTI submissions
Attify approach
Build the capability in-house
Attify helps teams shipping complex connected products move from one-time artifacts to reusable evidence models. We do this through CFSE and world modeling: an intermediate layer that connects business workflows, product behavior, technical reality, and certification evidence.
From one evidence cycle to many projections
Instead of "we did a pentest in Q3 and here is the report," your team keeps a structured product model: components, interactions, data flows, claimed security properties, and records of how each property was validated. That model can then be projected into a JC-STAR submission, KISA CIC application, Singapore CLS declaration, BSI label form, or UK PSTI statement of compliance.
Private capability building covers
- How to make a security world model of your product
- How to keep the model updated as the product changes
- How to map pentest and test results to the model
- How to create certification-specific projections from the same evidence base
This is suited for CISOs, security architects, compliance teams, product managers, and senior engineers who need the same evidence base to support multiple markets.
This article references publicly available information as of early 2026. Scheme requirements, fees, and MRA terms can change. Always verify directly with the relevant certification body before making compliance decisions. This is not legal advice.
For broader Attify research and tools, visit Research or Resources.