Cybersecurity Labelling Scheme mutual recognition between Singapore CLS and Japan’s JC-STAR STAR-1 allows an applicant to reuse the assessment of requirements that the two schemes treat as equivalent. For manufacturers selling across markets, this can reduce repeated conformity work. For a factory buyer, however, a label is not permission to connect a device to production, proof that both schemes are identical, or a legal mandate in Thailand. This guide turns mutual-recognition evidence into a practical procurement chain: RFP, evidence mapping, asset-and-zone fit, supplier remediation, FAT/SAT, and expiry/change monitoring.
What changed under the Japan–Singapore arrangement?
Japan’s Ministry of Economy, Trade and Industry and the Cyber Security Agency of Singapore signed a Memorandum of Cooperation on 18 March 2026. The arrangement took effect on 1 June 2026. It covers requirements treated as equivalent between JC-STAR STAR-1 and Singapore CLS Level 1 and provides a streamlined route for applying to the other scheme (METI; CSA announcement).
IPA explains that a CLS-labelled product applying for JC-STAR STAR-1 may omit checklist items corresponding to requirements already met under CLS. IPA lists a fee of JPY 140,000 including tax for the CLS-labelled product route, versus the standard JPY 198,000 including tax. The initial validity of a JC-STAR label is two years. These are scheme application conditions, not the total cost of factory assessment, testing, integration, translation, or network controls (IPA application guidance).
| Question | What mutual recognition can do | What it does not decide |
|---|---|---|
| Scheme application | Reuse findings for equivalent requirements and simplify the procedure | Automatically issue the other label |
| Product evidence | Make baseline evidence easier to organize and verify | Prove that every model, revision and firmware fits the factory use case |
| Factory procurement | Standardize the first evidence gate in an RFP | Accept OT risk or authorize connection to a production zone |
The business value is not “no assessment.” It is less duplicated conformity work, leaving more time for the risks that are unique to the factory.
Mutual recognition is not automatic equivalence
The word “recognition” is easily misread as automatic conversion. IPA’s description is narrower: a CLS-compliant product is treated as partially meeting JC-STAR STAR-1 criteria, and corresponding checklist items may be exempted. The applicant still follows the defined route, identifies the product and label, and supplies evidence for requirements that remain open or only partially covered. An application is also required in the reverse direction.
A buyer should not accept “CLS/JC-STAR ready” as a sufficient quotation line. Collect the following for each product:
- scheme name, level, label number and public verification URL;
- applicant/manufacturer identity and its relationship to the contracted supplier;
- product name, model, hardware revision, firmware and associated cloud service;
- issue date, expiry date and extension status;
- requirements reused through mutual recognition and requirements still needing evidence;
- vulnerability-reporting contact, update-support period and notification method;
- reassessment triggers for component, OEM, firmware or cloud changes.
A regional model can differ in radio module, firmware, power supply, cloud endpoint or optional function. Evidence is usable only when the labelled configuration matches the delivered configuration.
Do not flatten Singapore CLS Levels 1–4
Singapore CLS has four levels, with cumulative assessment tiers. CSA describes Tier 1 as baseline requirements based on ETSI EN 303 645, Tier 2 as adherence to the mandatory requirements of that standard, Tier 3 as lifecycle requirements plus software binary analysis, and Tier 4 as penetration testing by a test laboratory (CSA for manufacturers).
It is therefore inaccurate to say that a CLS Level 1 product has undergone third-party penetration testing. That assessment belongs to Level/Tier 4. A Level 4 result is still not a guarantee against every attack or every industrial deployment; it is evidence produced for a defined product, version, scope and test context.
| Evidence | Question it can answer | Question still requiring factory work |
|---|---|---|
| CLS Level 1 / JC-STAR STAR-1 | Has the product met the scheme’s baseline conformity route? | May it connect to this critical asset? |
| Higher level or added assessment | Has it completed deeper assessment activities? | Is the delivered version identical, and were factory threats covered? |
| Vulnerability policy | Is a reporting and update process defined? | What SLA and local deployment process apply in Thailand? |
| FAT/SAT record | Did the delivered configuration meet acceptance tests? | Who monitors changes and expiry after go-live? |
STAR-3 requirements released in July 2026 are a separate development
IPA announced on 13 July 2026 that STAR-3 security requirements for network devices and network cameras had been released (IPA JC-STAR). This matters to factories buying routers, gateways and cameras, but it is separate from the June 2026 STAR-1/CLS Level 1 mutual-recognition route.
An RFP should state the required level and product category instead of saying only “JC-STAR compliant.” Baseline evidence for an environmental sensor and assurance for a gateway bridging zones are not the same procurement decision. Publication of STAR-3 requirements also does not mean that every candidate product already holds a STAR-3 label. Check the requirements, application status and actual labelled-product register separately.
For product-specific evidence design, see our JC-STAR network-camera procurement guide and JC-STAR application guide.
Build IoT security procurement criteria as “label plus factory fit”
ETSI EN 303 645 V3.1.3 provides a security and data-protection baseline for consumer IoT. The standard itself says implementation is informed by risk assessment and threat modelling and that additional provisions can be appropriate for particular uses. It defines product requirements, not a universal testing or certification method (ETSI EN 303 645 V3.1.3).
That boundary is decisive in factory procurement. A consumer-IoT baseline is useful for topics such as avoiding universal default passwords, managing vulnerability reports and providing secure updates. Factory acceptance adds availability, safety, maintenance windows, industrial protocols, asset lifetime, remote access and interaction with legacy control equipment.
Even a labelled gateway should be rejected or remediated if, for example:
- its management interface is reachable from the entire production network;
- cloud endpoints, traffic direction, ports, DNS and certificate renewal are undocumented;
- automatic updates can interrupt a non-stoppable line at an arbitrary time;
- configuration backup and restoration are unavailable;
- only a shared administrator account exists and actions cannot be attributed;
- advisories reach headquarters but not the Thai maintenance team;
- update support ends well before the planned equipment life.
The label is an entry point for product-baseline evidence. Factory risk acceptance is the exit gate for the intended operating environment.
A six-gate overseas-factory IoT procurement workflow
Do not treat label verification as an isolated administrative step. Carry its evidence through the complete purchasing process. At each gate, define who reviews what evidence and who can approve an exception.
Gate 1: specify the response format in the RFP
“JC-STAR or CLS supported” is too vague. Define response fields, mandatory attachments and the difference between mandatory, conditional and informational requirements.
| RFP requirement | Supplier response | Required evidence | Accountable review |
|---|---|---|---|
| Scheme and level | Scheme, level, number, expiry | Public URL and label copy | Procurement + security |
| Covered build | Model, HW/FW, cloud, options | Configuration list, release notes | Engineering + IT/OT |
| Update support | Period, notification, signing, rollback | Policy, procedure, SLA | Maintenance + security |
| Vulnerability handling | Contact, triage, fix, urgent notice | Disclosure policy, escalation list | Security + legal |
| Communications | Destination, direction, port, crypto, certificates | Traffic matrix | Network owner |
| Remote maintenance | MFA, approval, time limit, recording | Access design, work instruction | Factory owner |
| Change control | Notice scope and lead time | PCN/EOL policy | Procurement + maintenance |
Avoid yes/no answers without evidence. Record the document version, applicable model and exception beside every “yes.” State that unanswered requirements are unverified, not implicitly compliant.
Gate 2: map scheme evidence to internal requirements
Map each company requirement to relevant scheme evidence, supplier evidence or a factory test. Perfect one-to-one mapping is not necessary. The purpose is to show which conclusion comes from which source and what remains open.
The mapping record should include internal requirement ID, risk, scheme clause, evidence, covered version, decision, exception, due date and approver. Record the page or section, issuer and date—not just a file name—so a future reviewer can reproduce the decision.
| Decision | Meaning | Next action |
|---|---|---|
| Conformant | Version-specific evidence satisfies the requirement | Proceed to Gate 3 |
| Conditionally conformant | Acceptable only with a restriction or compensating control | Register the condition and owner |
| Nonconformant | Requirement is not met | Remediate or select another product |
| Unverified | Evidence missing, ambiguous or version-mismatched | Request evidence; do not pass |
| Not applicable | Feature/use case is outside the requirement | Record rationale and approval |
Gate 3: decide asset-and-zone fit
The same sensor may be low risk in a meeting room and high impact when its gateway can reach a production controller. Identify the protected asset, connection path, data, control capability, downtime impact, recovery target and local maintenance capacity.
Ask what happens if the device is compromised: monitoring data disappears, false values reach MES, camera footage leaks, configuration changes, an attacker moves laterally toward a PLC, or a cloud outage removes control. Then constrain unacceptable paths through segmentation, traffic allow-lists, an OT DMZ, a jump host, local fallback, backups and monitoring.
Our industrial IoT gateway selection guide provides additional criteria. Label status and placement in an OT zone remain separate decisions.
Gate 4: close supplier remediation before contract award
“To be discussed during implementation” becomes a schedule and cost problem. Every remediation item needs an owner, deliverable, due date, retest method and consequence for non-delivery. If product modification is impractical, evaluate whether a time-bounded compensating control is sufficient.
Examples include a dedicated VLAN, firewall allow-list, outbound-only cloud connectivity, a jump host for administration, time-limited maintenance access, external monitoring and spare stock. Do not use the network to hide fundamental product gaps forever, such as no security-update support, no vulnerability contact, or an unchangeable shared password. Record the residual-risk owner and review date.
Gate 5: connect FAT and SAT to one acceptance record
Factory Acceptance Testing verifies the product, configuration and documentation before shipment or in the supplier environment. Site Acceptance Testing verifies the real factory network, identity services, time, monitoring and failure modes. DNS, NTP, proxies, certificates, VLANs and cloud access can make a FAT-passed device behave differently on site.
Include at least these security tests:
- model, HW/FW, labelled build and backup match;
- default credentials changed, named accounts, least privilege and MFA applied where required;
- allowed traffic works and prohibited traffic is blocked;
- update authenticity/integrity and failed-update recovery are verified;
- logs have synchronized time, required events, forwarding, retention and alerts;
- local behavior during cloud or WAN loss is safe and documented;
- factory reset, backup restore and spare-unit replacement work;
- remote access follows request, approval, enablement, expiry and recording controls;
- vulnerability-notification and urgent escalation are rehearsed;
- open items, interim controls, due dates and final approval are signed.
Keep inputs, expected results, actual results, logs, versions, tester and date. A pass that cannot be reproduced will not help an audit or incident response.
Gate 6: monitor label expiry and product change
IPA’s two-year initial JC-STAR validity is operational data, not a procurement-file footnote. Link the date to the asset register and track extension, firmware, EOL, vulnerabilities and cloud changes. Start review at a defined lead time before expiry so the factory can obtain renewal evidence, evaluate an alternative, strengthen a control or schedule removal.
Monitor more than the label:
- installed and approved firmware versions;
- vendor advisories, CVEs and emergency notices;
- label status, covered models and mutual-recognition conditions;
- product/component change and end-of-support notices;
- cloud endpoints, certificates, APIs and data-location conditions;
- factory zone, location, use-case and external-connectivity changes;
- supplier, distributor and OEM relationship changes.
Define which changes require a desk review, partial SAT, full reassessment or immediate disconnection. “Reassess when material” is too subjective without this decision table.
Example: introducing a labelled IoT gateway at a Thai factory
Consider a fictional project that uses a Singapore CLS Level 1 gateway for equipment monitoring in Thailand. This is a process example, not an assessment of a real product. At Gate 1, procurement asks for the public label record, covered model/firmware/cloud and update term. The submitted scope does not mention the optional LTE module, so the team records that configuration as *unverified*—neither rejecting the entire product nor passing it because the base unit is labelled.
At Gate 2, scheme baseline evidence, the supplier’s traffic specification and the factory’s remote-access requirements are mapped separately. Evidence about authentication and updates does not answer SIM management, private-mobile connectivity, cloud endpoints or local escalation. A wildcard destination in the traffic sheet is broken down into required FQDNs, ports, directions and certificate checks.
At Gate 3, engineering confirms that the gateway reads PLC status but does not issue control commands. Because the initial design places it on the same switch, acceptance is conditioned on a monitoring VLAN, firewall rules, an OT-DMZ relay and an administrative jump host. PLC control must continue during cloud loss, and a full gateway buffer must not disturb control traffic. Gate 4 closes the LTE configuration record, update contacts, Thai first response and certificate-renewal procedure before award.
FAT verifies the specified firmware, traffic, accounts, signed update and restore. SAT repeats the decision in the real DNS, NTP, VLAN, firewall, proxy and monitoring environment, including WAN loss, cloud outage, certificate error, restart and buffer limit. Gate 6 then links the label’s two-year validity, firmware, LTE module, cloud API, certificates, SIM and distributor contract to one asset ID. A renewed label does not automatically cover a changed delivered build, and a valid label does not eliminate review of a changed cloud API.
Design the evidence register around product, version, location and decision
A folder of PDFs and emails does not scale across factories. The evidence register should index the manufacturer/model/HW/FW, scheme/level/number/URL/expiry, factory/line/zone/use, traffic and identity configuration, decision/exception/residual-risk owner, lifecycle notices, and FAT/SAT results. Use a unique product-build key and link it to the factory’s asset ID so reviewers can navigate from scheme evidence to the installed unit, tests, exceptions and updates.
Every decision has a time context. Store the decision date, assessed version, next review and change triggers together. Procurement owns commercial scope and change/EOL clauses; engineering owns function and FAT; IT/OT security owns evidence, traffic and zone fit; maintenance owns local update/recovery and SAT; legal/quality owns warranties and records; the asset owner accepts residual risk. A single shared register prevents each department from recreating the same evidence.
Applying the schemes in a Thai factory
The Japan–Singapore arrangement described here is not presented as a Thai legal mandate. A company may make a label mandatory under its own purchasing policy, customer contract or export-market requirement, but that is distinct from a Thai statutory obligation. Check the product category and applicable rules separately, while using CLS/JC-STAR as one source of product-security evidence.
Operating language is also a control. If the scheme evidence is in English or Japanese but a Thai maintenance technician cannot use the isolation, update or recovery procedure, the control will fail during an incident. Localize the runbooks and emergency contacts and test them with the people who will execute them. Keep label, certification, conformity and factory acceptance as separate concepts in translation.
Clarify the commercial chain as well. The manufacturer, brand owner, scheme applicant, Japanese importer, Thai distributor, local integrator and cloud operator may be different companies. The contract should identify who sends advisories, who answers first, who holds replacement stock and who supports recovery after a distributor change.
Ten questions for a procurement review
- Which scheme and level apply, and can the label be verified publicly?
- Do the delivered model, hardware, firmware and cloud service match the labelled scope?
- Which requirements are reused under mutual recognition, and what application evidence remains?
- What is the expiry date, and who owns extension or renewal?
- Do the vulnerability contact and update-support period cover the equipment life?
- Are endpoints, ports, identity, crypto, certificates and remote access documented?
- Is compromise or outage tolerable in the proposed OT zone?
- Have compensating-control cost and operating effort been included in product comparison?
- Does the contract define FAT/SAT failure, remediation, retest and schedule responsibility?
- Can the asset register monitor expiry, vulnerabilities and changes after go-live?
Any “we will check after installation” answer is cost and schedule uncertainty. Close it before award or document a conditional approval with budget, due date and risk owner.
Common failure modes and corrections
A label image is accepted without model/version matching
Compare the public register, label scope, delivered bill of materials and release notes. Record the physical unit’s model and version at receipt and in the asset register.
Mutual recognition is described as automatic conversion
Use the precise wording: a streamlined application that reuses findings for equivalent requirements. Keep the remaining application, evidence, fee, review and label issuance in the process.
CLS Level 1 is described as penetration tested
Return to CSA’s level/tier description. Penetration testing by a test laboratory is Level/Tier 4. Commission an additional scoped test if the use case requires it.
Label acquisition replaces factory connection approval
Test asset/zone fit, traffic, accounts, updates, failure behavior and monitoring. The factory owner accepts residual risk and authorizes connection.
Expiry and EOL remain in a procurement folder
Link the asset, contract, vulnerability and maintenance records by product ID. Route alerts to a role mailbox or ticket queue rather than one employee.
Headquarters documents replace local operation
Provide Thai-language procedures, escalation, restore drills, spare units and permissions. Headquarters can own scheme evidence while the factory owns operating evidence, with a clear handoff.
FAQ: cybersecurity labelling mutual recognition
Does JC-STAR mutual recognition automatically issue a Singapore CLS label?
No. It streamlines the application by reusing findings for requirements recognized as equivalent. The applicant must still use the other scheme’s route and meet remaining document and requirement conditions.
What is the JC-STAR STAR-1 fee for a CLS-labelled product?
IPA lists JPY 140,000 including tax, versus the standard JPY 198,000 including tax. These are application fees, not the full cost of evidence preparation, factory tests, network work or localization.
How long is the initial JC-STAR label validity?
IPA states two years. Record the label, covered build and expiry in the asset register, and review important product or use-case changes even before expiry.
Has a Singapore CLS Level 1 product undergone penetration testing?
That should not be assumed. CSA places test-laboratory penetration testing at Level/Tier 4. Verify the actual level and assessment scope.
Are JC-STAR or CLS legally mandatory for a factory in Thailand?
This article does not claim such a Thai mandate. Check company policy, customer contracts, export destinations, product category and applicable law independently.
Can a labelled gateway connect directly to the production network?
No label makes that decision. Evaluate the asset, traffic, privilege, updates, outage impact, monitoring and recovery, and use an OT DMZ or other controls where required.
Conclusion: move saved effort to factory-specific risk
Cybersecurity Labelling Scheme mutual recognition is a useful way to reuse conformity work between JC-STAR STAR-1 and Singapore CLS Level 1. It is not automatic full equivalence, factory connection permission or a Thai legal mandate. The practical result comes from an evidence chain: RFP, version-specific mapping, asset-and-zone fit, remediation, FAT/SAT, then expiry and change monitoring. Use the time saved on duplicated checks to examine production uptime, safety, remote support and local operations—the risks the label was never meant to accept for you.
TOMAS TECH supports overseas-factory IoT procurement from the early stage: structuring an RFP, mapping labels to evidence, reviewing OT network fit, and designing FAT/SAT acceptance items. If you are still separating scheme application requirements from factory acceptance, you can discuss the approach with us through our contact page.
