“The manufacturer has JC-STAR certification, so its device is acceptable.” That conclusion is too broad for an industrial IoT purchase. JC-STAR applies to registered products and model ranges, not automatically to every product made by a company. A buyer must also distinguish the assurance level, current status, validity period, covered firmware, deployment conditions, and support lifetime.
This guide explains how procurement, OT, IT, quality, and maintenance teams at a Thai factory can evaluate JC-STAR-supported products and carry the evidence into an RFP, FAT, SAT, and operational asset register. It is a cross-manufacturer verification workflow, not a ranking of certified manufacturers.
Why a list of JC-STAR-certified manufacturers is not a purchasing decision
The IPA official list is a useful starting point. A tally of the official Excel file last updated on 4 September 2026 found 338 registrations, all 338 shown as valid at that point, and 138 unique label holders. The full-width and half-width forms of “Star 1” were normalized as the same level. The point-in-time category totals included 139 energy-related registrations, 86 communications devices, 42 security-related devices, nine controllers such as PLC/DCS, four IoT gateways, two manufacturing/distribution-related products, and two autonomous robots. From 1 August 2026 onward, the file contained 21 registrations associated with 18 label holders.
These are snapshot figures derived from the official Excel file as of 4 September 2026. Registrations and statuses can change. The list must be retrieved again at purchase approval, delivery, and during operation. A note saying that a product was valid in September 2026 is not enough evidence for a later audit.
The 138 label holders do not represent approval of every product made by those businesses. One company may have both registered and unregistered series. Even within a series, only certain model numbers or hardware revisions may be covered. The procurement key is therefore the combination of registration number, product name, model range, assurance level, status, and validity period—not the supplier name alone.
The IPA JC-STAR product list publishes registration number, business, product name, level, status, acquisition date, and validity period. Possible statuses are not limited to valid; they may include grace after expiry, expired, or revoked. Check the official list immediately before a decision rather than relying on a search snippet, distributor presentation, or old PDF.
First principle: JC-STAR is not a guarantee of complete security
IPA explicitly states that a label does not guarantee that a product is completely secure. Procurement teams should treat it as structured conformity information against defined criteria, not an unconditional pass. Residual risk depends on the factory use case, network connections, threat exposure, maintenance process, and consequence of failure.
The assessment method also differs by level. Star 1 and Star 2 are self-declarations based on a vendor self-assessment checklist. Star 3 and Star 4 use an independent third-party evaluation. The number of stars should not be used as a simplistic product ranking. The RFP should instead identify the required assurance for the use case, who assessed what, and which configuration was within scope.
A sensor with no direct internet route is not equivalent to a gateway that brokers remote maintenance traffic at a production-network boundary. Cameras, energy-management devices, and controller-adjacent equipment also have different attack paths and downtime consequences. JC-STAR is one selection input; it does not replace a factory-specific risk assessment.
Verify every JC-STAR-supported product across seven fields
Use one evidence sheet containing the following seven fields. Procurement should not own it in isolation. OT, IT, quality assurance, maintenance, and—where necessary—legal should work from the same record.
1. Registration number
The registration number is the primary key linking evidence. Put the same number in the RFP response, quotation review, purchase approval, FAT report, SAT report, and asset register. A manufacturer name or marketing product name alone cannot support traceability when registration information changes.
Require the supplier to submit the official list URL and registration number. If a screenshot is kept as evidence, record the retrieval date, reviewer, and source URL, and where practical preserve the day’s list data. Do not approve a device based only on a label image in sales material.
2. Covered model range
Compare the quoted sales model character by character with the registered product name, series, and model range. A suffix may identify a region, radio module, power specification, memory size, or enclosure that falls outside the registered variant.
Even if the base unit is covered, an external communications module or option card may not be part of the evaluated configuration. Ask for a configuration table that includes the base unit, mandatory options, accessories, management software, and cloud service. If naming differs between the quotation and assessment evidence, request a formal mapping from the manufacturer instead of accepting “equivalent model” as an explanation.
3. Status
Confirm that status is valid on the date of purchase approval. Because the official list can contain states other than valid, historic acquisition is insufficient. Record checks at RFP close, purchase order approval, and delivery so that a project with a long lead time can detect a change.
“Application pending” or “planned to comply with JC-STAR” is different from a completed registration. IPA warns about misleading expressions such as a claim that a product is scheduled to be compliant. Applications for Star 1 opened on 25 March 2025, and as of 31 July 2026 IPA advised that a surge in applications was causing confirmation to take longer than usual. If the contract allows certification by delivery, define in advance the substitute, schedule, review, and contractual outcome if registration is not completed.
4. Validity period
Place the validity end date beside the planned start and end of factory use. When validity will end soon after delivery, ask about renewal, renewal evidence, and the response if the registration is not renewed. Long-lived equipment requires a review strategy across the maintenance period, not only a check at purchase.
Do not confuse the label validity date with the physical end of a device’s usable life. Expiry does not automatically mean a device becomes unsafe that day, but it is a trigger to reassess whether the assurance basis remains applicable. For example, the asset process may open a review task 90 days before expiry when that lead time has been agreed internally. The 90-day example is an internal control choice, not a universal JC-STAR rule.
5. Published assessment information
Review the published assessment or conformity information to understand the criteria, level, and evaluated configuration. Record whether the evidence is a vendor self-declaration for Star 1/2 or an independent evaluation for Star 3/4. A note that merely says “starred product” loses an important distinction for audit.
Map available evidence to the controls needed by the factory. These may include credential management, initial passwords, software update, protected communications, logging, and vulnerability-reporting contacts. Where the published material does not establish a control, obtain supplier evidence or include a test in FAT. An unknown item should remain open with an owner and due date rather than being converted into “compliant.”
6. Firmware conditions
Confirm the firmware version covered by available evidence, the version shipped, the latest recommended version, the update route, signature verification, and rollback method. A registered device running a different firmware may require additional analysis.
In a Thai factory, an equipment builder may prefer an older firmware for stability while IT requires a newer version to address vulnerabilities. Neither principle should be applied blindly. Use change control that considers compatibility, vulnerability exposure, required downtime, test evidence, and recovery. Record the outgoing version at FAT, the installed version at SAT, and the current version in the operational register, then investigate any mismatch.
7. Support period
The registration validity period and vendor support period are separate. Record the planned end of security updates, end of sale, end of maintenance, and end of any associated cloud service. Where dates are not fixed, require the notification channel, notice period, critical-vulnerability policy, and migration support for a successor model.
Industrial equipment often remains in operation for years. Updateability and replaceability can matter more than the unit price. If spare inventory is used to extend service, do not leave unsupported devices indefinitely. Record compensating controls such as segmentation, restricted access, and monitoring, together with an approved retirement date.
Turn an IoT security procurement standard from a supplier rule into a product rule
A specification that says only “the manufacturer must be JC-STAR certified” can be interpreted as satisfied when the company holds one registration for an unrelated device. A more precise requirement is: “The proposed sales model, including the offered configuration and planned delivery firmware, must fall within the applicable registration scope on the specified verification date.”
Decide by use case whether JC-STAR is mandatory, scored, or may be satisfied by equivalent evidence. Making it universally mandatory in a small supplier market can damage maintainability or business continuity. Conversely, a clear assurance requirement may be valuable for boundary gateways, remotely managed equipment, or devices deployed at scale. Connect the requirement to product risk and connectivity.
The IPA product page added a CLS mutual-recognition list on 1 June 2026 and a PSTI declaration-of-conformity list on 14 January 2026. Singapore’s CSA states that the Japan–Singapore memorandum was signed on 18 March 2026 and that mutual recognition took effect on 1 June 2026. Examples of products in scope include smart-home equipment, alarms, and IoT gateways or hubs, with the aim of simplifying a manufacturer’s application for another country’s label.
Do not generalize that arrangement to every product, every level, or automatic acceptance in Thailand. If a candidate appears on a mutual-recognition list, verify the list entry, scope, model, and conditions individually.
Write verifiable JC-STAR procurement requirements into the RFP
Avoid a single yes/no question asking whether a product is certified. Define the evidence format, the baseline date, and responsibility for changes. A comparison sheet can include the following fields.
| RFP field | Supplier response and evidence | Buyer verification |
|---|---|---|
| Registration | Number, official URL, acquisition date | Match against official list |
| Product scope | Sales model, hardware revision, options | Match the quoted BOM |
| Assessment | Level, method, published result | Self-declaration or third party |
| State | Current status, validity period | Relation to PO and delivery dates |
| Firmware | Evaluated, shipped, and recommended versions | Difference and change control |
| Update | Signature, distribution, rollback, outage | Can it be tested in FAT/SAT? |
| Support | Security updates, EOL/EOS, notification | Does it cover expected service? |
| Vulnerabilities | PSIRT contact, notice, urgent response | Connect to factory escalation |
| Change notice | Model, component, firmware, cloud changes | Trigger for reassessment |
| Exceptions | Gaps, compensating controls, deadline | Risk-owner approval |
State the response baseline date, for example the official list on the proposal date, and reserve the right to recheck before purchase. Contract terms should require notification if status or model scope changes before delivery, prohibit an unapproved “equivalent” substitution, and route any alternative through reassessment.
For network infrastructure, the JC-STAR network-equipment RFP guide covers management planes, remote service, logging, and segmentation. For camera projects, use the JC-STAR network-camera procurement guide to extend assessment to video data, user accounts, recorders, and cloud links.
FAT: make the shipping configuration auditable
FAT confirms that documentary conformity matches the physical configuration. Print the registration number in the test record and preserve evidence of the device label, nameplate, sales model, hardware revision, serial number, and firmware.
Match model, options, and firmware
Reconcile the quotation BOM, manufacturing BOM, shipping BOM, and physical unit. For optional communications modules, management servers, mobile applications, or cloud services, identify what is inside the registration and assessment scope and what requires a separate factory assessment.
Test initialization and authentication
Test initial credential handling, first-login changes, unnecessary accounts, privilege separation, password recovery, and certificate enrollment. A secure factory default can be weakened during local integration when all units are assigned a shared password. Verify the work instruction and completion evidence.
Test update, recovery, and logging
Exercise authentic-firmware validation, recovery from a failed update, rollback restrictions, configuration backup, and event-log extraction. A device that cannot be updated in practice will delay vulnerability remediation even if the published support period is long. Use the test environment to understand downtime and connect the result to production change approval.
Control nonconformities before shipment
Do not close a FAT issue with pass/fail alone. Record the corrective action, due date, retest, and exception approver. A model outside registration scope, an unknown firmware baseline, or a missing update procedure is more expensive to correct after installation. Use a shipment-release gate that can stop the device until evidence is complete.
SAT: reassess under the Thai factory’s actual connection conditions
A device that passed FAT enters a different risk environment once connected to the plant network. SAT should cover location, zones, access paths, time synchronization, monitoring, backup, and asset registration—not only functional operation.
Confirm connection to the designed VLAN or security zone and check for unexpected internet traffic or exposed management ports. Where remote support is required, test a process with request, approval, time limitation, logging, and explicit closure instead of an always-open path.
Then verify time synchronization, log forwarding, alert monitoring, backup, and recovery. Security logs cannot support incident investigation if their timestamps differ. A device’s ability to produce logs is also insufficient if there is no destination, retention, or responsible reviewer.
Finally, link the physical asset ID to the JC-STAR registration number in the operational register. If firmware or configuration changes during commissioning, record the impact on the evaluated baseline and consult the supplier where required. SAT completion starts operational assurance; it does not end security work.
Use three gates: purchase, delivery, and operation
Verification is a lifecycle control, not a one-time checklist.
Purchase gate
Confirm registration number, model scope, level, status, and validity. Compare supplier evidence with the official list. Perform the use-case risk assessment, and assign compensating controls and an approver to any unmet requirement. Record the retrieval date of the official data in the purchase approval.
Delivery gate
Use FAT and receiving inspection to confirm that delivered model, hardware, firmware, and options match the approved configuration. Retrieve the official list again to detect a post-order status change. Quarantine a mismatch before installation and perform a difference assessment.
Operational gate
Monitor validity, support end, vulnerability notices, firmware updates, and configuration changes. Use both a scheduled review and event triggers such as a critical vulnerability, supplier notice, network change, or change of use. Ask whether the actual device still matches the verified baseline—not merely whether a label once existed.
Build an operational register that links the evidence
At minimum, maintain registration number, manufacturer, product, sales model, serial number, hardware revision, location, asset owner, operational owner, level, assessment method, official status, acquisition date, validity end, assessed firmware, current firmware, security-support end, vulnerability contact, last review, next review, exception, compensating control, and retirement plan.
The information does not have to live in a single procurement system, CMDB, equipment register, or maintenance platform. It must, however, be cross-referenced through the registration number and internal asset ID. Assign ownership: procurement for contract and supplier notices, OT for configuration and downtime, IT for network and vulnerabilities, maintenance for the physical unit and replacement, and quality for acceptance evidence.
An Excel register can be a sound starting point when field definitions, editors, due dates, history, and approval rules are controlled. Conversely, an expensive asset tool does not create procurement evidence if model scope and firmware are left blank.
How to position JC-STAR in Thailand
Teams searching for “JC-STAR Thailand” should not assume that JC-STAR is universally required by Thai law. The practical use described here is to apply JC-STAR information within a Japanese group’s procurement governance or a customer requirement at a Thai facility. Thai laws, industry rules, radio and import requirements, and contractual obligations still require product-specific review.
On 12 March 2026, Thailand’s NCSA announced consultation on draft IoT cybersecurity guidelines for general users, noting alignment with ISO/IEC 27400/27402 and ETSI EN 303 645. This is relevant evidence of an active policy direction, but a consultation draft should not be presented as final law or a mandatory rule for every factory.
depa’s dSURE is a certification framework for IoT and digital products of Thai legal entities, with Security, Safety, and Functionality criteria. It should not be described as identical to JC-STAR or already mutually recognized with it. If both may apply, compare the eligible organizations, product scope, criteria, applicant, and legal or commercial effect separately.
METI’s usage guide presents JC-STAR as reference information for procuring IoT products incorporated into systems in specific sectors. The buyer must therefore convert scheme information into controls. A label in the RFP is not enough; the requirement must connect to factory risk, evidence, acceptance tests, and monitoring.
Responsibilities by department
Procurement manages the registration number, sales model, price, lead time, contract, and supplier change notices. OT defines the use case, downtime impact, network configuration, fallback operation, and available update window. IT and security review authentication, communications, logging, vulnerability response, and remote access. Quality assurance audits whether the evidence remains continuous from the RFP response through FAT, SAT, and the acceptance record.
The machine builder or system integrator must be accountable as a provider of configuration information, not treated only as a product shipper. The contract should require advance notice and reapproval for component changes, substitute products, firmware changes, or cloud-service specification changes. The factory must also record USB-based updates or configuration changes made through local operational judgment.
Governance meetings should focus on the number of unverified items, deadlines, owners, and downtime impact rather than the star count or manufacturer name recognition. States such as evidence verified, conditionally approved, corrective action open, expired, and exception approved allow procurement and operations to manage the same facts with a shared vocabulary.
Common failure patterns
Turning the manufacturer list into an approved-vendor list
A company-level list can approve an unregistered product by mistake. Manage the registration number and sales model together and repeat the check for each proposal.
Accepting a logo in sales material
A logo or “compliance planned” claim does not establish current scope or status. Use the official list and retain the registration number, validity, and retrieval date.
Checking only when the order is placed
Model, firmware, or status can change before delivery. Use purchase, delivery, and operational gates.
Treating certification and support as one date
Registration validity, end of sale, maintenance end, security-update end, and cloud-service end are different. Maintain separate fields and let the earliest constraint inform upgrade planning.
Treating Star 1 and Star 3 as the same evidence
Star 1/2 use self-declaration; Star 3/4 use independent evaluation. Match assurance needs to the use case and close any gap with evidence or tests.
Guessing equivalence with Thai schemes
JC-STAR, the NCSA draft guidelines, and dSURE differ in purpose and status. Do not claim identity, mutual recognition, or legal obligation without primary evidence for the exact case.
FAQ: JC-STAR-certified manufacturers and IoT purchasing
Does a JC-STAR-certified manufacturer have coverage for all its products?
No. Coverage applies to products, model ranges, and configurations on the official list. Confirm that the quoted sales model and hardware revision are within scope.
Is a JC-STAR-supported product completely secure?
No. IPA explicitly says the label is not a guarantee of complete security. Combine its level and assessment method with a risk assessment for the factory use, network exposure, and downtime impact.
What should a JC-STAR procurement requirement contain?
Include registration number, official URL, sales model, hardware revision, level, assessment method, status, validity, covered firmware, update process, support period, vulnerability contact, change notice, and exception handling. State the baseline date and require a delivery-time recheck.
Can we buy a product described as “planned for JC-STAR compliance”?
That is a project decision, but it must not be treated as already registered. If registration by delivery is allowed, define the alternative, schedule, reassessment, and contractual treatment if it is not achieved.
Is JC-STAR legally mandatory for Thai factories?
This guide does not treat it as a universal mandate for all Thai factories or IoT devices. It can be used as group or customer procurement governance, while Thai legal, sector, radio, import, and contractual requirements are verified separately.
Are depa dSURE and JC-STAR mutually recognized?
Do not assume so. dSURE has Security, Safety, and Functionality criteria for eligible Thai entities. Compare each scheme’s product scope, applicant, criteria, and effect using primary information.
Must a device be shut down immediately when label validity ends?
Do not make an automatic decision from the date alone. Assess current status, vulnerabilities, update condition, exposure, downtime consequence, and compensating controls. Any continued use should have a risk owner, expiry, and replacement or remediation plan.
Conclusion: connect the registration number to the operational asset
Finding a JC-STAR-certified manufacturer is only the start of IoT procurement. Verify registration number, model scope, status, validity, published assessment, firmware conditions, and support period at product level. Carry the same identifiers through the RFP, FAT, SAT, and asset register. The official Excel snapshot on 4 September 2026 contained 338 registrations and 138 unique label holders, but those figures and each product’s status are not permanent. Rechecking at purchase, delivery, and operation turns a label into an effective control.
If your Thai factory is still designing its candidate-product sheet, RFP response matrix, FAT/SAT test record, or asset and firmware register, contact TOMAS TECH. We can help structure the evidence flow around your existing procurement, OT, IT, quality, and maintenance responsibilities without starting from a preferred manufacturer.
Sources
- IPA: JC-STAR scheme
- IPA: JC-STAR product list
- IPA: registered products and recognition lists
- IPA: application information for Star 1 and Star 2
- METI: guide to using IoT product security conformity information
- Singapore CSA: mutual recognition with Japan
- Thailand NCSA: consultation on draft IoT cybersecurity guidelines
- depa: dSURE
