Certifying IoT products across Japan, Korea, and Singapore in 2026
If you're responsible for security on a connected product expanding into Asia-Pacific in 2026, you've almost certainly run into questions about what's actually required. This piece from Attify aims to cut through the confusion and help you take relevant, strategic steps to make your compliance process faster and more effective.
Your Japanese partner is asking about JC-STAR readiness. Your Korean distributor needs to know about KISA CIC. A Singaporean enterprise lead mentions CLS. Meanwhile, your German prospects are demanding the BSI IT Security Label, and your CFO just wants a single-sentence answer on what all of this is going to cost.
The short answer: the regional certification landscape has consolidated dramatically in the last 18 months, and a single certification often does carry you into multiple markets. But the way mutual recognition actually works is more conditional than the headline announcements suggest, and there are specific places where you'll still need to do the work twice.
If you aren't careful, you will end up paying for the exact same testing five times over.
This post walks through the current state of the IoT cybersecurity labeling map across Japan (JC-STAR), Korea (KISA CIC), and Singapore (CLS), with tie-ins to the UK (PSTI) and Germany (BSI IT Security Label) — because they're all now connected.
How do IoT cybersecurity MRAs work between Japan, Korea, and Singapore in 2026?
There are now formal Mutual Recognition Arrangements (MRAs) connecting most of the major consumer IoT cybersecurity labels. Because almost all of these schemes share the same technical DNA — specifically, ETSI EN 303 645 — certifying once and getting recognized in multiple jurisdictions is a real outcome.
Below are the major certification schemes and their current bilateral arrangements:
Mutual recognition map · 2026
Active and pending bilateral IoT cybersecurity arrangements. Singapore CLS holds the broadest reciprocity web; Japan's JC-STAR–CLS arrangement takes effect June 2026.
Singapore
CLS
- Finland: CLS L3+ ↔ Cybersecurity Label
- Germany: CLS L2+ ↔ BSI IT Security Label
- Korea: CLS L3 ↔ KISA CIC Basic+
- UK: Recognized under PSTI
- Japan: CLS ↔ JC-STAR (effective June 2026)
Korea
KISA CIC
- Singapore: CIC Basic+ ↔ CLS L3
- Germany: CIC Basic / Standard ↔ BSI Smart Consumer Devices
Japan
JC-STAR
- UK: JC-STAR L1 meets PSTI statutory requirements
- Singapore: JC-STAR ↔ CLS (effective June 2026)
- US / EU: Active negotiations ongoing
The US NISTIR 8425 and EU CRA are also heavily aligned with these baselines, though formal MRAs are still being hammered out.
When do mutual recognition arrangements not apply?
The MRAs are real, but they don't auto-translate work perfectly. If you've started to suspect that you're paying for the same testing repackaged five times — you're right.
MRAs are not blanket passes
Reciprocity is highly specific. Korea and Singapore recognize each other — but only if you have KISA CIC Basic mapping to CLS Level 3.
If you have KISA CIC Lite, that doesn't get you a Singapore CLS label automatically. If you want CLS Level 4, you can't reach it through any current MRA — you'll need a Singapore-specific local lab evaluation regardless of what other certifications you hold.
MRAs cover specific product categories
Most of these arrangements explicitly cover smart consumer devices — smart cameras, smart speakers, home automation hubs, health trackers, smart appliances. If your product lives on the boundary, you may find the MRA doesn't apply, even though your certification looks similar.
A small-business IoT gateway sometimes deployed in consumer settings; an industrial sensor with a consumer-product SKU; a connected medical-adjacent product that doesn't quite trigger MDR but isn't a “consumer device” either — these all sit in places where category definitions vary across schemes and aren't always aligned.
Product-category fit matters more than vendors expect, and you have to verify it explicitly per scheme — not assume it from the underlying technical baseline.
MRAs cover the label, not the evidence
When you submit for a new label in a different jurisdiction — even one where reciprocity applies — you typically need to provide the original certification documentation, application materials in the target country's format, and sometimes additional materials specific to the receiving scheme.
Reciprocity reduces the cost and time, but it isn't automatic. Vendors usually find that an MRA submission is still 30–50% of the work of a fresh certification.
This is the largest hidden cost in this whole process.
High tiers always require local labs
JC-STAR STAR-3 and STAR-4 require third-party evaluation by IPA-recognized assessors and are specifically aimed at government procurement and critical infrastructure.
KISA CIC requires third-party laboratory testing at all levels, including Lite. Singapore CLS Levels 3 and 4 require approved third-party labs.
If you're targeting any of these higher tiers — and you'll need to for serious government or enterprise procurement — your existing certification in another country doesn't substitute for the local lab evaluation, even when an MRA exists for lower tiers of the same scheme.
What's the technical baseline behind JC-STAR, KISA CIC, and Singapore CLS?
When you step back from the certification headlines, the underlying technical baseline is converging across jurisdictions — while the evidence formats are still diverging.
The convergence is good news.
Most of these schemes are testing for largely the same things: no universal default passwords, a working vulnerability disclosure mechanism, a defined security update period, secure communication of sensitive data, secure storage, secure update mechanisms, attack-surface minimization, and secure-by-default configuration.
The ~15 controls that show up in ETSI EN 303 645, JC-STAR STAR-1, KISA CIC Basic, Singapore CLS Level 2, and UK PSTI all substantially overlap.
The divergence is where vendors lose time.
Each scheme wants the evidence in a slightly different form:
Singapore CLS
Declarations of conformity backed by supporting evidence. Binary analysis at Level 3 and pentesting at Level 4.
JC-STAR (Japan)
STAR-1 takes a self-declaration against a checklist. STAR-3 and STAR-4 require formal evaluation reports from IPA-recognized assessors.
KISA CIC (Korea)
Third-party lab reports at every level, structured to KISA's procedural format.
BSI IT Security Label (Germany)
Product manufacturer declarations referencing applicable standards, with additional detail for higher product categories.
What does this mean? You can have a perfectly compliant product, with all the right controls in place, and still spend weeks per submission — re-formatting evidence, re-running specific tests in the format the receiving lab expects, and dealing with edge cases where one regime's interpretation of “secure update mechanism” differs from another's.
This is the gap between the controls are the same and the evidence is the same. The MRAs close the first gap. The second gap is yours to handle — and the vendors who handle it well have started thinking about their security work differently.
How to plan your certification strategy
Optimize for reach vs investment
Pick the certification that gives you the most MRA reach for your first investment.
Right now, Singapore CLS Level 3 has the broadest reciprocity web — it carries to Finland, Germany, Korea (CIC Basic+), and Japan. If you have to start somewhere, that's often the highest-leverage anchor for consumer IoT.
JC-STAR Level 1 is the cheapest baseline if you primarily care about Japan and the UK.
KISA CIC is the right starting point if you're already in Korea and want German market reach.
Plan ahead for local lab evaluations
Don't assume MRA reciprocity is your only or final certification work.
Build your roadmap assuming that for any market where you need higher-tier procurement reach — government, critical infrastructure, large enterprise — you'll do a local lab evaluation regardless of what you hold elsewhere.
Plan the time and budget accordingly. The MRAs are real, but they're a discount, not a free pass, and the discount only applies in the bands of tier and product category where the bilateral specifically maps.
Why does the same product need different evidence packs for each certification?
How are you solving the evidence problem? Are you producing a separate evidence pack per submission?
This is where most businesses think poorly — and end up paying a lot more in their time and finances than they should.
If you're producing a separate evidence pack for each submission — distinct from the testing you already did — you're paying repeatedly for work you've already done. If you can structure this well, you can significantly reduce the time required from your team to produce the evidence, as well as the overall cost incurred to do so.
There is no magic formula. The key is to think about the evidence as a structured asset that can be created once and delivered as required.
The deeper shift — and why it matters more than the MRA web
The MRA web will keep expanding. The real question is what that means for you — and how you plan for the unseen implications of shifting geopolitical and regulatory trends.
Japan is currently negotiating with the US and EU.
Singapore is actively pursuing more partners.
Korea has shown willingness to sign with anyone whose technical baseline aligns.
Over the next two years, the practical effect is that certification-as-label-acquisition will get easier across borders.
But that makes the underlying problem more visible, not less.
The real cost of multi-market IoT certification is not the labels. It's the evidence structure behind the labels.
If your security work produces an unstructured pentest report and a checklist spreadsheet, then for every new market — MRA-covered or not — you have to manually translate that into the receiving lab's preferred format.
You'll do this five times across the five schemes that matter to you. And then again every time a product variant ships, and again every time a scheme updates its requirements, and again every time a new MRA opens up and you want to take advantage of it.
The ones who've internalized this are starting to think differently about what their internal security work outputs.
This is where Attify helps businesses streamline their evidence generation process — by bringing in the initial insights required to build a capability inside the organization. We do this through a methodology called CFSE — which enables you to build a World Model of your product, or multiple products.
So instead of “we did a pentest in Q3 and here's the report” — you can produce a structured World Model: what components, what interactions, what data flows, the explicit security properties you claim hold over that model, and a record of how each property was validated. Think of it as an intermediary layer that translates your business and user workflows and maps them to the technical realities.
The output of this World Modeling can then be projected into a JC-STAR submission, a KISA CIC application, a Singapore CLS declaration, a BSI label form, or a UK PSTI statement of compliance — with the same underlying evidence, just packaged for the audience.
If you're a vendor staring at three or four certifications across the next two years, this is the key decision — a one-time effort that optimizes all future compliance and certification evidence work. Not because it makes the certifications themselves easier — they're still going to be work — but because it changes the marginal cost of every additional certification from another full evidence cycle to another projection of the same evidence.
Build the capability in-house
If you're tired of paying the “reformatting tax” on every new certification, Attify can help your team transition to a structured evidence model.
If you want your team to build this capability in-house, we offer a private capability-building program — delivered as onsite or remote training through the Offensive Intelligence Engineering (OIE) program. It covers:
What the program covers
- How to make a World Model of your product
- How to keep your World Model updated
- How to map your actual pentest and test results to the World Model
- How to create projections in the required certification format
All of this is customized for your industry and business requirements. The training is ideal for a range of seniority levels: CISOs, security architects, compliance teams, product managers, and senior developers.
Attify works with teams shipping complex, connected, behaviorally-rich products — the kind where security work has to produce a durable, projectable asset rather than one-time artifacts.
Begin by sending an enquiry — we'll help you shape the right scope.
This article references publicly available information as of early 2026. Specific scheme requirements, fees, and MRA terms can change; always verify directly with the certification body before making compliance decisions. We are not lawyers; this is not legal advice.