Japan’s JC-STAR and Singapore’s CLS are now mutually recognised, and the arrangement took effect on 1 June 2026. If you read that news and immediately wondered what it means for equipment purchasing at your Thai plant, here is the conclusion first. The Japan-Singapore MRA cannot be applied directly to procurement standards for a Thai site. Thailand is not a party to the arrangement, and there is no Thai equivalent of JC-STAR or CLS in the first place.
So what should a Thai site use as its baseline instead? This article works through four practical questions: where to draw the line between the head office standard and local optimisation, how to communicate a Japanese-origin requirement to a local supplier who has never heard of the scheme, who between the site and the head office holds final authority over the procurement standard, and how the Thailand Cybersecurity Act B.E. 2562 actually relates to any of this. The aim is not a summary of regulations but wording you can paste into tomorrow’s request for quotation.
A three-minute recap of JC-STAR and the Japan-Singapore MRA
Before the Thailand-specific discussion, here is the minimum background needed to reason about procurement. The full explanation of the scheme itself belongs elsewhere, so this section stays short.
JC-STAR shows the security conformity of an IoT product in tiers
JC-STAR is a Japanese scheme that makes the security requirement level of an IoT product visible from the outside, expressed in star tiers. It is operated by IPA. For a buyer, the value is that you do not need to read and compare security specification sheets product by product; the tier on the label tells you the floor the product has cleared.
The structure of the scheme, the difference between the tiers, and the argument that the date requirements become mandatory matters more than the date a label appears are covered in What Is JC-STAR 2026: The Requirement Date Matters More Than the Label. This article picks up where that one leaves off and concentrates on the Thai side.
What actually changed on 1 June 2026
On 18 March 2026, Japan’s Ministry of Economy, Trade and Industry, represented by State Minister Ino, and the Cyber Security Agency of Singapore, CSA, signed a memorandum of cooperation in Tokyo on the mutual recognition of cybersecurity schemes for IoT products. The mutual recognition entered into force on 1 June 2026.
What was recognised is that part of the baseline requirements of the JC-STAR Star 1 tier and part of the baseline requirements of Level 1 of Singapore’s Cybersecurity Labelling Scheme, CLS, are equivalent. Not everything was declared equivalent, and this concerns the entry tier on both sides. Keep both qualifiers in mind.
The practical effect is lighter paperwork and a lower fee
Seen from the manufacturer’s side, the effect is concrete. When a CLS-conformant product applies for JC-STAR Star 1, the submission consists of three items: the application form for CLS-conformant products, the checklist for CLS-conformant products, and the CLS conformity label. The fee reduction applies to that Star 1 application, which costs 140,000 yen including tax instead of the usual 198,000 yen, a difference of 58,000 yen. Applications go to the JC-STAR application desk at the Technology Evaluation Department of IPA’s Security Center. For an application at Star 3 or above, a CLS declaration of conformity is added, but that declaration goes to the JC-STAR evaluation body rather than through the same route as the Star 1 application to IPA. Do not read the fee reduction as extending to Star 3 and above.
In other words, the substance of the MRA is a mechanism to reduce duplicated effort for manufacturers who want to sell in both markets. Its effect on a buyer’s procurement standard is indirect: what changes is the supply of labelled products, not the standard itself.
Each recognition is bilateral and none of them covers Thailand
This is the starting point for everything that follows. Singapore was not the first. METI signed a memorandum with the United Kingdom on mutual recognition with the PSTI Act in London on 5 November 2025, and that mutual recognition started on 1 January 2026. The Japan-Singapore MRA is the second such arrangement. For the U.S. Cyber Trust Mark and the EU Cyber Resilience Act, the information IPA publishes describes an information-sharing stage; no mutual recognition has been agreed or has entered into force. And no public information confirming any negotiation with Thailand has been identified.
The point that matters is that each of these is a country-to-country arrangement. Going from one recognition to two does not widen the effect beyond those two countries. Thailand is inside none of the frameworks.
So the only defensible statement today is that the Japan-Singapore MRA is a bilateral framework and Thailand sits outside it. Because there is no basis for it, do not write “eventually Thailand too” into an internal paper.
Thailand has no equivalent of JC-STAR or CLS

Now to the Thailand-specific part. First, let us pin down the facts.
Thailand is not a party to the MRA
The Japan-Singapore MRA is an arrangement between those two governments. There is no situation in which it applies when your Thai site buys equipment locally. Buying a CLS-conformant product in Thailand does not reduce any JC-STAR fee for you and does not remove any step on the Thai side. The fee reduction applies to a manufacturer applying for JC-STAR in Japan.
Going one step further: Thailand has no cybersecurity certification or labelling scheme for IoT devices comparable to JC-STAR or CLS at all. That also removes the option of “reading the requirement across into the local scheme”, because there is nothing to read it across into.
The existing Thai scheme that touches IoT devices is NBTC type approval
For readers who assume Thailand must have something, here is the correct reference point. The existing Thai scheme relevant to IoT devices is type approval by the NBTC, the National Broadcasting and Telecommunications Commission.
What that scheme examines centres on the radio requirements for wireless equipment. Cybersecurity requirements are not within its scope. So when a local vendor tells you a product is “already certified in Thailand”, that almost certainly refers to NBTC type approval and provides no security assurance. Being legally permitted to transmit in Thailand and being secure are entirely separate propositions.
Placing the three jurisdictions side by side gives the following picture.
| Item | Japan, JC-STAR | Singapore, CLS | Thailand |
|---|---|---|---|
| Nature of the scheme | Assesses IoT product security conformity and shows it on a label | Comparable security labelling scheme | No equivalent scheme exists |
| Main authority | IPA | CSA | Not applicable |
| Security requirements assessed | Yes | Yes | NBTC type approval does not cover security requirements |
| Label a buyer can rely on | Star tiers | Levels | None |
| Mutual recognition status | Recognised with CLS, in force 1 June 2026 | Recognised with JC-STAR, in force 1 June 2026 | Not a party |
When you share this table internally, do not present the Thai column as a weakness. The absence of a scheme also means you are free to write the requirement yourself, which is exactly what the rest of this article is about.
Three things the absence of a scheme means on the ground
To keep this concrete, here is what actually happens during a purchase.
First, proposals from local vendors will not arrive with third-party evidence of security conformity attached. Even if the head office issues a rule saying “choose products that carry a label”, most of the candidates available through the Thai supply chain are outside the scope of any such label.
Second, there is a real risk of misreading “certified in Thailand” as a security claim. As noted above, it is most likely NBTC type approval, which examines a different set of things.
Third, because you cannot screen candidates by the presence of a label, you have to write the requirements yourself. The flip side is that once you have written them, your Thai procurement standard no longer depends on whether a scheme exists.
Apply the head office standard as is, or relax it locally

With no local scheme to lean on, the only source of a baseline is the head office standard. Which immediately raises the question of whether that standard should be applied in Thailand unchanged.
There are only three options
Structurally, the choice collapses into three.
The first is to apply the head office standard as it stands. You keep a single standard, which is by far the easiest thing to explain in an audit. The cost is that when the equipment available through the Thai supply chain does not meet it, procurement simply stops.
The second is to maintain a separate, relaxed standard for the Thai site. More things become purchasable, but you now have two standards, and over time nobody can tell which one applies to a given purchase. If the reason for relaxing is not recorded, by the next refresh cycle no one can explain why the bar was lowered.
The third is to differentiate by equipment category. Instead of treating all devices identically, you vary the strength of the requirement according to where the device sits in the network. It costs more to operate, but in practice this is the option least likely to break down.
Axis 1: where the device sits in the network
The first axis is placement. A device connected directly to an external network or a cloud service, a device connected only to the plant control network, and a device not connected to anything carry different levels of risk. There is no obligation to hold them to the same bar.
Axis 2: whether anything other than local sourcing is possible
The second axis is substitutability. Whether a device can be exported from Japan or can only be bought inside Thailand changes how much room you have to hold the line. For devices whose maintenance depends on a local vendor, look beyond the device specification to the access path used during maintenance.
Axis 3: replacement cycle and contract form
The third axis is time. A device attached to production equipment that will stay in service for five years or more and an IT device replaced every few years differ in how long today’s exception keeps having effect. Devices tied to a lease or a maintenance contract can usually only be re-evaluated at contract renewal, which also has to be planned for.
Combining the three axes produces the following arrangement.
| Equipment category | Examples | How to set the bar | Handling of exceptions |
|---|---|---|---|
| Externally connected devices | Cloud connection gateways, remote maintenance routers, VPN appliances | Apply the head office standard unchanged | Exceptions not granted as a rule |
| Devices on the control network | Data collection terminals on production lines, industrial switches, shop-floor IoT sensors | Head office standard by default, exception request only where no alternative exists | Approve with an expiry date, recorded together with the compensating measure |
| Non-networked devices | Standalone instruments, standalone display units | Local judgement is sufficient | Only confirm whether connection is planned later |
The single most important part of using this table is writing down that you relaxed the bar when you relaxed it. Granting an exception is not the problem. The problem is an exception that goes unrecorded, hardens into the default, and is mistaken for the standard by whoever takes over. Every approved exception needs an expiry date and a re-evaluation date.
The upstream discussion, meaning what should go into the selection criteria in the first place, is covered in JC-STAR for Manufacturing — Device Procurement Criteria for 2026. This article deals with operating those criteria at a Thai site, so if the criteria themselves are still undecided, start there.
How to communicate JC-STAR and CLS to a local supplier
A standard that does not travel to the supplier does not move procurement. This is where the process most often stalls.
Do not lead with the name of the scheme
Assume that a local supplier in Thailand has not heard of JC-STAR or CLS. The schemes apply in different markets; this is not a failing on the supplier’s part. Consequently, writing “must be equivalent to JC-STAR Star 1” in a request for quotation will usually be ignored or answered with something that misses the point.
What needs to travel is not the name of the scheme but the substance it demands. Listing the points you want confirmed in plain sentences, without proper nouns the reader does not recognise, produces accurate answers far faster.
A three-step way to communicate
In practice the following order works.
Step 1 is to write the requirements as a plain list with no scheme name in it. Is the initial password unique per unit, or is a change forced at first start-up? What is the plan and the method for delivering software updates? Are unused communication ports and services disabled by default? Who is the contact and what is the notification method when a vulnerability is found? When is support scheduled to end? Every one of these can be answered without knowing anything about any scheme.
Step 2 is to avoid limiting the form of evidence to one thing. If third-party certification exists, take it; if not, take a manufacturer’s declaration of conformity; if that is not available either, accept a configuration procedure document with screenshots. Products arriving with third-party certification are the minority in the Thai supply chain, so insisting on a single form of proof deletes your candidate list.
Step 3 is to supply a deadline and a response format. Free-text questions come back as prose you cannot compare. Provide a table with three choices per line, compliant, not compliant, and compensating measure available, plus a field to describe the compensating measure.
When the answer is “our product is certified in Thailand”
You will get this answer often. When you do, ask which certification. If it is NBTC type approval, that centres on the radio requirements for wireless equipment and is not an answer to the security questions you asked. There is no need to contradict the supplier; simply say that separately from that certification you want the following items confirmed, and return to the requirement table.
CLS-conformant products do sometimes reach the Thai supply chain. In that case you can read the product as meeting the Level 1 requirements, but that describes the product as shipped. Without the matching installation settings, network segmentation and password practice, the label means nothing, and that holds regardless of whether the product carries a label.
Who owns final authority over the procurement standard
Even with the requirements written, an unclear owner stops the process. This part is governance, not regulation.
There are three patterns
| Pattern | Where authority sits | Suits | Weakness |
|---|---|---|---|
| Centralised | Head office decides the standard and all exceptions | Many sites, dedicated security function at head office | Time zones and language delays stall local purchasing |
| Devolved | The Thai site decides its own standard and exceptions | Deep local engineering bench, no one at head office able to judge | Standards diverge by site and cannot be explained group-wide in an audit |
| Two-tier | Standard from head office, first-instance exception decisions local, head office reviews afterwards | Most Japanese manufacturing sites in Thailand | Becomes an empty formality unless exception records are actually kept |
In practice we recommend the two-tier pattern. It is the only shape that keeps procurement moving without losing group-level explainability. The head office owns the standard itself and the right to re-evaluate exceptions; the site owns time-limited first-instance authority.
Build the exception route before you need it
Do not get the order wrong. The exception route is issued together with the standard, not after it. If only the standard arrives, the local team has two choices: halt any purchase that cannot meet it, or quietly ignore it. Neither is a state you want.
The exception request form should capture six things: the device concerned, the requirement that cannot be met, why it cannot be met, the compensating measure, the expiry date, and the re-evaluation date. With those six, a successor can pick up the file.
Decide who holds the exception register
This is the piece most often left out. Once approved, an exception has to appear on a register and be re-evaluated when it expires. Decide at the outset, and name one person, whether that register is maintained by the head office or the site. A register without a named owner stops being updated within about six months.
How the Thailand Cybersecurity Act B.E. 2562 fits in

Finally, the legal question. Getting this wrong in an internal briefing leads either to effort spent on work that was never required, or to unwarranted comfort.
The scope is operators of critical information infrastructure in eight sectors
The Thailand Cybersecurity Act B.E. 2562, the 2019 act, regulates operators of critical information infrastructure, CII. The sectors in scope are national security, public services, financial services, ICT and telecommunications, transportation and logistics, energy and public utilities, public health, and any other sector designated by the NCSC, the National Cyber Security Committee. That is eight.
The obligations placed on organisations in scope are organisational obligations: carrying out a cybersecurity risk assessment at least once a year and submitting a summary report of the results to the Office within 30 days of completing it, establishing the prescribed guidelines, providing information on system design and infrastructure operation, and reporting to the Office and the competent regulator when a cyber threat occurs, among others.
Production equipment and IoT devices are not themselves regulated
This is the point this article most wants to land. The act is not a product certification scheme. It does not define security requirements for factory production equipment or IoT devices and require conformity to be demonstrated. What it regulates is the operation of organisations in the designated sectors, not device specifications.
It follows that if your Thai site buys a device that falls short of the head office standard, that in itself is not a breach of this act. It equally follows that you cannot claim, on the basis of this act, that device security is assured because Thai law is being complied with.
No breach, but no substitute assurance from the law either
To summarise: the Thailand Cybersecurity Act B.E. 2562 neither prohibits nor requires anything in respect of factory equipment procurement. That means a high degree of freedom, and it also means there is no externally imposed floor.
In Japan a JC-STAR tier serves as a rough floor; in Singapore CLS plays the same role. Thailand has neither, so the floor has to be set by you. The head office standard and exception route described above are the mechanism for holding a floor of your own making.
One caveat: if your site itself operates in one of the eight sectors listed above, that is a different conversation. In that case, separate it from the equipment procurement discussion and confirm the organisational obligations with legal counsel.
Practical checklist for building a Thai site procurement standard
Everything above, ordered by what to do first. Work down the list and you will have a first draft of the standard.
- Confirm whether a documented head office security standard for equipment procurement exists at all
- Confirm whether it explicitly states that it applies to overseas sites
- Confirm whether it is written purely in terms of scheme names such as JC-STAR. A standard written only in scheme names is unusable in Thailand
- If it is written in scheme names, expand the substance of what is demanded into plain requirement statements
- Sort the devices your Thai site buys into three categories: externally connected, control network connected, and not networked
- Decide, per category, whether the head office standard applies unchanged or an exception request is available
- Create the exception request form with its six fields: device, unmet requirement, reason, compensating measure, expiry date, re-evaluation date
- Name one person, at head office or at the site, to maintain the exception register
- Create a requirement confirmation table for local suppliers, using no scheme names and answerable as compliant, not compliant, or compensating measure available
- Allow three forms of evidence: third-party certification, manufacturer declaration, or a configuration procedure document
- Build submission of the requirement confirmation table into the request for quotation template as a mandatory item
- Ask legal counsel whether your own business falls into any of the eight sectors covered by the Thailand Cybersecurity Act
- Plan how already-installed equipment will be brought back against the standard at its next refresh
Frequently asked questions
Is there any point buying JC-STAR labelled equipment for a Thai site
There is, but treat it as a shortcut in selection rather than as a legal effect. No Thai rule asks for JC-STAR, so the presence of a label changes nothing about your legal position. What it does do is act as a proxy for the requirements the product already satisfies, sparing you the work of having your requirement table filled in from scratch. Where importing from Japan is a real option, that efficiency argument holds.
Could Thailand join a JC-STAR mutual recognition arrangement later
There is nothing available on which to base a judgement. JC-STAR mutual recognition started with the United Kingdom under the PSTI Act on 1 January 2026 and entered into force with Singapore’s CLS on 1 June 2026. With the United States and the European Union the relationship is at an information-sharing stage, with no agreement and nothing in force. No public information about negotiations with Thailand has been identified, so the honest position is that it can be neither asserted nor ruled out. Avoid writing “mutual recognition with Thailand is expected” into an internal paper and design your standard on the basis that no scheme exists today.
If we buy a Singapore-made device with CLS certification for the Thai site, is it safe
You can say it met a defined set of requirements as shipped. But CLS Level 1 is the entry tier, and what the Japan-Singapore MRA recognised is part of the baseline requirements of JC-STAR Star 1. On top of that, device security changes substantially with post-installation configuration and operation. Without changing the initial password, disabling unused ports, segmenting the network and applying updates, no label makes a device safe. A label is a starting point, not a destination.
Does the Thailand Cybersecurity Act require anything of our plant
In the context of equipment procurement, nothing is required because of this act. It applies to operators of critical information infrastructure in the eight designated sectors and does not regulate production equipment or IoT devices as products. That said, if your business falls into one of those sectors, such as energy and public utilities or transportation and logistics, organisational obligations may arise. Separate that question from the equipment discussion and take it to legal counsel.
What if the head office IT department and the Thai site disagree
The strongest protection is to not debate the decision rights during a live case. If, at the time the standard is issued, you have already established that the standard comes from head office, that first-instance exception decisions are local, and that head office reviews afterwards, there is no authority to fight over on an individual purchase. If a disagreement is already underway, separate whether the dispute is about the standard itself or about granting an exception. It is usually the latter, and a time-limited exception approval resolves it.
Summary
The main points from this article.
- The Japan-Singapore MRA is a bilateral framework and Thailand is not a party, so it cannot be applied directly to procurement standards for a Thai site
- The MRA was signed on 18 March 2026 and entered into force on 1 June 2026, recognising part of the baseline requirements of JC-STAR Star 1 and CLS Level 1 as equivalent
- Its practical effect is simplified paperwork and a fee reduction from 198,000 yen to 140,000 yen when a CLS-conformant product applies for JC-STAR, a difference of 58,000 yen, none of which changes a buyer’s standard
- Thailand has no IoT device security certification or labelling scheme comparable to JC-STAR or CLS
- Thai NBTC type approval centres on the radio requirements for wireless equipment and does not include cybersecurity requirements
- With no local scheme to lean on, the only source of a baseline is the head office standard, and the choice collapses into uniform application, uniform relaxation, or differentiation by category
- Differentiation by category is the least fragile in practice, varying the bar across externally connected, control network connected and non-networked devices
- Communicate to local suppliers in terms of substance rather than scheme names, and accept three forms of evidence: third-party certification, declaration of conformity, or configuration documentation
- The two-tier governance pattern, standard from head office, first-instance exception decisions local, review afterwards at head office, is the easiest to operate
- Every exception request must carry six fields: device, unmet requirement, reason, compensating measure, expiry date, re-evaluation date
- The Thailand Cybersecurity Act B.E. 2562 covers CII operators in eight sectors and does not regulate factory equipment itself, so there is no breach and equally no substitute assurance from the law
- JC-STAR mutual recognition started with the United Kingdom under the PSTI Act on 1 January 2026 and the Japan-Singapore MRA is the second arrangement, while the United States and the European Union remain at an information-sharing stage and no information about negotiations with Thailand has been confirmed
The first thing to do is not to canvass vendors or compare devices. It is to pull out one head office equipment procurement standard and check whether it is written in scheme names or in substantive requirements. If it is written in scheme names, that standard will not function in Thailand. Rewriting it into requirement statements is the real first step in building a Thai procurement standard.
TOMAS TECH supports Japanese manufacturers operating in Thailand with plant IT and OT deployment, including the PEGASUS production management system. We also take questions on drafting procurement standards, framing requirements for local suppliers, and aligning with head office policy, from the stage where nothing has been decided yet. If you are simply trying to get a clear picture of where you stand, that is a fine place to start, so please get in touch through our contact page.
References
- IPA – JC-STAR application for CLS conformant products
- METI – State Minister Ino signed a memorandum on the mutual recognition of JC-STAR and the Singapore CLS cybersecurity labelling scheme
- IPA – JC-STAR mutual recognition application for UK PSTI Act conformity
- ScanNetSecurity – Mutual recognition of the Japanese and Singaporean IoT security labelling schemes
- Thailand Cybersecurity Act B.E. 2562, full English translation PDF
- ib-lenhardt – Type Approval Thailand, NBTC radio equipment certification
- IPA – JC-STAR scheme overview