JC-STAR for Overseas Sites: RFP and FAT/SAT for Thai Factories

When a Japanese headquarters considers using JC-STAR at overseas sites, the first point to settle is what the label does not do. It does not turn Japanese certification into automatic proof of compliance in Thailand. Its practical value is different: it gives headquarters a common baseline for IoT device security procurement, then lets the Thai plant translate that baseline into evidence for the RFP, vendor selection, FAT, SAT and post-go-live update monitoring.

Executive conclusion: turn the JC-STAR label into site acceptance evidence

JC-STAR is Japan’s voluntary labeling scheme for a broad range of IoT products that send or receive data using IP. STAR-1 expresses baseline requirements common to covered products. Higher levels add requirements according to product category and intended assurance. STAR-1 and STAR-2 use vendor self-declaration assessed through the scheme and labeled by IPA; STAR-3 and STAR-4 require an independent third-party evaluation.

A valid label does not by itself prove that a device has been installed and operated safely at a Thai factory. IPA explicitly distinguishes between having security functions and continuing to use those functions safely. Network segmentation, secure configuration, identity, logs, backup, vulnerability handling, update deployment, end-of-support management and secure disposal remain site and operator responsibilities.

The headquarters procurement standard should therefore have two layers. Layer one asks whether the product and exact version are covered by an appropriate, currently valid JC-STAR label and can be verified on the IPA product page. Layer two asks whether the product can be deployed, connected, operated, updated and retired safely in the Thai plant’s actual architecture, with evidence produced during FAT and SAT. The label is the entry gate; acceptance evidence and lifecycle monitoring complete the control.

Five boundaries to understand before using JC-STAR in Thailand

1. A Japanese voluntary scheme is not a Thai legal approval

Using a JC-STAR-labeled product can make group procurement more consistent. It does not automatically satisfy Thai cybersecurity, telecommunications, radio, import, personal-data, industrial-safety or customer-specific obligations. The applicable requirements depend on the product’s function, connectivity, processed data and the plant’s business context.

The RFP should state that JC-STAR is a group procurement baseline, not a substitute for local compliance. Assign responsibility among local legal counsel, the plant’s IT/OT and engineering teams, safety, privacy, the local system integrator and the manufacturer before bidding. This avoids discovering a missing license, approval or customer requirement just before acceptance.

2. The label covers a product, not the complete factory system

IPA describes the object of labeling as a purchased or supplied IoT product, or an IoT device together with an essential associated service. A complete system is currently outside the label’s scope. A labeled network camera does not mean that the VMS, cloud, VPN, switches, identity platform, service laptop, configuration and monitoring operation have all been certified.

Record the registration number against manufacturer, product name, exact sales model, regional SKU, hardware revision, firmware revision, required service, installed location, network zone and operational owner. If the suffix or regional variant differs, verify that it is within the labeled scope using the IPA product information page and manufacturer evidence.

3. The highest star number is not automatically the right requirement

STAR-1 is the common baseline. STAR-2 and above take product-category characteristics into account, so criteria can differ between categories even at the same level. If an RFP mandates a level that is not available for the device category, it may eliminate all bidders or encourage ambiguous claims of future compliance.

Before setting the gate, confirm that the product is in scope, that criteria for its category are operational, and what levels can actually be obtained on the procurement date. Then decide whether the label is mandatory, scored, planned for a defined future milestone, or replaceable by specifically identified equivalent evidence. Do not treat “JC-STAR ready,” “application planned,” or “under application” as equivalent to an issued label. IPA warns against claims that could make an unlabeled product appear already approved or likely to be approved.

4. Mutual recognition is not a universal passport

As of 9 September 2026, procedures for mutual recognition with the UK PSTI regime have been in operation since 1 January 2026. For a PSTI-compliant product applying for JC-STAR STAR-1, three JC-STAR criteria can be accepted and the published STAR-1 fee is JPY 140,000 including tax, compared with the normal JPY 198,000. In the other direction, a JC-STAR holder seeking evidence for UK PSTI must make an additional application and meet conditions such as English product and vulnerability information; IPA lists an additional administrative fee of JPY 5,500 including tax.

IPA also publishes procedures related to Singapore’s Cybersecurity Labelling Scheme after the March 2026 memorandum. Each recognition is limited by scheme, direction, technical requirements, product scope and procedure. It does not mean that every requirement in the other country is automatically satisfied, and it is not mutual recognition with Thailand. A procurement matrix should separate scheme, direction, accepted criteria, additional submission, fee and territorial scope.

5. A valid label does not remove update monitoring

Labels have validity periods. The IPA product list can show states such as valid, grace period pending extension, expired, voluntarily withdrawn or revoked. IPA’s current application page says a new label is valid for up to two years from issue, regardless of level. A point-in-time PDF saved during procurement is therefore not a permanent control.

The contract should address the vulnerability contact, minimum security update period, notification deadline, update method, label expiry or withdrawal, serious vulnerabilities, replacement devices, rollback and local labor. Headquarters can periodically reconcile IPA registration data, while the Thai plant reconciles installed firmware and configuration against the asset inventory.

A two-layer IoT security procurement standard for Japanese headquarters

Keep product evidence separate from site evidence. The former is primarily supplied by the product vendor; the latter is created jointly by the integrator and plant.

For the product layer, confirm that the label’s QR code or URL reaches the IPA-managed product page. IPA tells purchasers to check for a URL beginning https://jc-star.ipa.go.jp/conformance/. A copied logo in a sales presentation is not sufficient evidence.

For the plant layer, confirm that only intended communications are permitted, unnecessary services are disabled, unique credentials are set, administrative paths are separated and events are exported. A capable product deployed with default credentials, unrestricted ports, an always-on vendor VPN and no update owner does not achieve the procurement objective.

For broader architecture, read our OT security guide for manufacturing in Thailand and overseas plant IoT implementation guide. If your role concerns the scheme application itself, use the JC-STAR application guide for 2026. For candidate identification, see procurement and manufacturer verification for JC-STAR-certified IoT devices. This article deliberately avoids repeating an application walkthrough or product list; it focuses on the path from headquarters policy to overseas RFP, FAT/SAT and update monitoring.

How to write a factory RFP: separate requirement, answer and evidence

Avoid Yes/No questions such as “Do you support JC-STAR?” Package every requirement with the supplier response, required evidence, verification gate and treatment of nonconformance.

RFP clause 1: identity between the proposed item and labeled scope

Requirement example: For each IoT product, submit manufacturer, product name, sales model, regional SKU, hardware revision, firmware revision, essential associated service, JC-STAR registration, level, validity date and IPA product URL. Explain why the proposed configuration is within scope.

Evidence: IPA page, nameplate, version matrix, bill of materials and architecture. Reconcile distributor claims with information from the label holder.

RFP clause 2: applicable level and gaps

Requirement example: State only the level already issued at bid time. Do not describe an unissued higher level as supported. If the requested level is unavailable for the category, explain why and map equivalent controls to evidence.

Evidence: Current IPA criteria, completed evidence matrix, defined scope of any external assessment and approved exception. Keep the product roadmap separate from issued evidence.

RFP clause 3: authentication and secrets

Requirement example: Permit unique credentials per device or a secure enrollment flow. Prohibit universal default credentials. Describe first boot, replacement, factory reset, ownership transfer and secret rotation.

Evidence: Configuration screens, API documentation, enrollment logs, demonstration from factory state, and a configuration export with secrets removed.

RFP clause 4: vulnerability handling and security updates

Requirement example: State the vulnerability contact, supported languages, response target, advisory method, security update period, package signing and integrity verification, distribution path, offline option, rollback control, emergency update and recovery from failure.

Evidence: Published disclosure policy, support-period statement, signature verification log, example package, recovery procedure and historical advisory. “Long-term support” is not a date; require an end date or objective calculation rule.

RFP clause 5: communications, logging and time

Requirement example: Declare every destination, protocol, port, DNS dependency, certificate, cloud service and remote-service path. Export authentication, configuration, update, administrative and abnormal communication events, aligned with the factory time source.

Evidence: Communications matrix, packet capture, sample logs, time configuration, cloud-disconnection behavior and data retention/deletion policy.

RFP clause 6: supply chain and change notification

Requirement example: Notify the purchaser when software components, third-party clouds, outsourced maintenance, components, firmware, end of sale or end of support could affect security or label status.

Evidence: SBOM or equivalent component inventory, change process, EOL/EOS notice and reassessment flow. The purpose of an SBOM is not possession of a file; it is to identify affected field assets when a component vulnerability appears.

Score evidence maturity, not just “label: yes/no”

A useful comparison table evaluates at least seven axes:

1. Authenticity and validity: registration, model and version match.
2. Fit of level: the level is sensible for category and consequence.
3. Updateability: signed online and offline update paths, failure recovery and controlled rollback.
4. Operational visibility: logs, inventory, firmware and destinations can be centrally checked.
5. Local support: Thai/English response, spares, local labor and emergency escalation.
6. Lifecycle: advance EOL/EOS notice, support duration, component change and cloud-exit plan.
7. Testability: FAT/SAT environment, configurations and failure cases can be demonstrated.

Mark each item mandatory, scored or exception-controlled. A cheap product that requires an overseas visit for every update, stops when a cloud closes, exports no logs and gives no EOL notice has high total ownership risk. Equally, demanding controls unrelated to the plant risk adds lead time and operating burden without improving the outcome.

FAT: freeze the delivered product and its evidence before shipment

Factory Acceptance Testing occurs in the manufacturer or integrator environment before delivery. For JC-STAR procurement, it must do more than display a label PDF.

FAT-1: labeled scope against delivered BOM

Reconcile purchase order, delivery BOM, packaging, nameplate and management-interface model/version. If an essential cloud plan is part of the labeled configuration, ensure it is contracted. Obtain written scope confirmation for regional SKUs or changed wireless modules.

FAT-2: secure initialization and unique configuration

Start from factory state. Perform enrollment, removal of unnecessary accounts, least-privilege roles, certificate installation and secure backup. Test two units to confirm that secrets are not shared. Factory reset should not expose the previous owner’s data or credentials.

FAT-3: measured communications allowlist

Compare the declared matrix with packet capture. Look for undeclared DNS, NTP, analytics, telemetry or remote-support endpoints. Test behavior without cloud reachability. For encrypted sessions, verify peer authentication, certificate expiry, revocation and re-enrollment—not merely the presence of TLS.

FAT-4: update, tamper and rollback cases

Test a valid update, invalid signature, interrupted transfer, insufficient space and incompatible package. The device should reject unauthorized code, remain or return to a safe state and generate evidence. If rollback is supported, prevent uncontrolled downgrade to known-vulnerable releases.

FAT-5: logs and a vulnerability tabletop exercise

Generate failed administrator login, configuration change, time change, update, reboot and certificate error events. Export them to the future log destination. Use a simulated critical advisory to walk through notification from vendor to headquarters, plant and SI, affected-asset identification, compensating control and patch decision.

Every result should include test ID, linked requirement, serial number, version, precondition, action, expected result, actual result, evidence file, deviation, owner and due date. A signature saying “passed” cannot reproduce the decision later.

SAT: accept the device in the Thai plant’s real operating conditions

Site Acceptance Testing verifies the actual people, network, time source, power, service path and language. A passed FAT never makes SAT unnecessary.

SAT-1: zones and reachability

Use the real VLANs, firewall, DMZ, jump host and VPN. Confirm that only approved paths work. Look for direct production-to-internet access, always-on vendor tunnels, shared maintenance PCs and administrative ports exposed to the business LAN. Record temporary exceptions with owner, expiry and monitoring condition.

SAT-2: local identity lifecycle

Create roles for Thai operators, maintenance, external SI, auditors and Japanese administrators. Apply MFA, approval, emergency access, periodic recertification and immediate termination for transfers or departures. A Japanese-only runbook is not an operational control at a Thai site.

SAT-3: power, WAN, DNS/NTP and cloud failure

Within safe operating limits, simulate power loss, upstream network loss, DNS/NTP outage and cloud unavailability. Observe safe production behavior, local continuation, data gaps, restart order, time drift and reauthentication. Security must not create unnecessary availability loss, but protection must not silently disappear during a fault.

SAT-4: update through the real maintenance process

Update using the actual bandwidth, proxy, approvals and maintenance window. For remote execution from Japan, define local safety check, permit to work, abort criteria and recovery owner. After update, recheck firmware, configuration diff, communications, logs and control function.

SAT-5: evidence handover and local exercise

Headquarters and plant jointly accept the asset inventory, network diagram, communications matrix, accounts, backup, update procedure, vulnerability contact, EOL list and FAT/SAT evidence. The local owner must demonstrate receiving an alert, identifying the asset, applying initial isolation and sending usable evidence to the vendor.

Put update monitoring in the contract

After go-live, monitor change—not only the label expiry date. Monthly review can reconcile installed versions, vulnerabilities, vendor notices and pending updates. Quarterly review can check IPA status, support period, privileged accounts, communication destinations and exceptions. Annual exercises can test recovery, escalation, supplier change and disposal.

Classify changes in three groups:

• Routine change: a minor fix or approved configuration update; use the standard procedure and refresh evidence.
• Security-significant change: authentication, encryption, destination, cloud, major component or update mechanism; repeat relevant FAT or limited SAT.
• Conformity-impacting change: a specification or version change that may affect the declaration; obtain evidence from the label holder and document whether notification, withdrawal or reapplication is required.

When a vulnerability is announced, do not act on CVSS alone. Assess reachability in the actual plant, prerequisites, control and safety impact, compensating controls and update feasibility. If immediate patching is unsafe, assign time-limited measures such as traffic restriction, feature suspension, credential rotation and enhanced monitoring.

Exception management for specialized overseas equipment

Legacy machinery gateways, long-lead special devices and regional SKUs may have no labeled candidate. A verbal waiver destroys the standard. An exception record should include:

• product, location, function, data and reachable networks;
• why the label cannot be met and the market-research date;
• alternative standard, test, third-party report and vendor evidence;
• compensating segmentation, allowlisting, monitoring, service restriction, spare and replacement plan;
• residual risk, approver, expiry and review date.

Tie expiry to the next shutdown, support date or expected replacement availability. Track open and overdue exceptions at headquarters so that a temporary decision does not become a permanent hidden architecture.

A 90-day rollout for headquarters and one Thai factory

Days 0–30: establish scope and baseline

Name owners in procurement, cybersecurity, plant IT/OT, engineering, quality and the local SI. Inventory current IP devices; classify JC-STAR scope, label, criticality, updateability and EOL. Publish the RFP template and exception form, and establish the IPA product page as the authoritative label check.

Days 31–60: run one product through FAT and SAT

Select a camera, gateway or sensor that can demonstrate updates and logs. Receive an evidence-based RFP response, test identity, version, hardening, communications, update and logs in FAT, then install it in a limited Thai plant zone for SAT of access, failure, recovery and local operation.

Days 61–90: embed lessons in contract and monitoring

Return every test gap to the standard clauses, inspection criteria, support SLA and change-notification terms. Assign a schedule and owner for IPA status and installed-version reconciliation. Put overdue updates, exceptions, support end and critical vulnerabilities into plant and management review.

The goal is not to certify every plant in 90 days. It is to close one repeatable loop from requirement and evidence to acceptance and lifecycle control, then replicate it across sites.

Frequently asked questions about JC-STAR at overseas sites

What is JC-STAR?

It is Japan’s voluntary conformity and labeling scheme for security functions in a broad range of IP-capable IoT products. STAR-1 is the common baseline, while higher levels address category and assurance needs. It does not certify every product or an entire installed system.

Is JC-STAR mandatory for a factory in Thailand?

JC-STAR itself is not a blanket Thai legal mandate. A Japanese corporate group may adopt it as an internal procurement baseline. Thai law, sector rules, customer terms and site risk still require separate review.

Does a label secure the complete factory system?

No. It covers the registered product and defined scope. Network architecture, cloud, accounts, configuration, service access, operators and update processes must be verified through design review, FAT, SAT and operation.

Should an RFP require STAR-1 or STAR-3?

Do not choose by number alone. Consider the available criteria for the category, product criticality, production and safety consequences, threat exposure and need for independent evaluation. Check current IPA availability before issuing the RFP.

What are the fee and validity period?

As of 9 September 2026, IPA lists the normal STAR-1 application fee as JPY 198,000 including tax, excluding evaluator or verification-provider fees. A new label is valid for up to two years from issue. Different levels, extensions and mutual-recognition routes have different conditions, so recheck IPA immediately before application.

Does mutual recognition remove additional checks?

No. UK PSTI and Singapore CLS arrangements cover defined criteria and procedures and may require additional applications and information. They do not create automatic compliance in Thailand. Verify direction, product scope, territory, excluded requirements and fees for each case.

What is the minimum procurement evidence?

Require the IPA product URL, registration, exact model and versions, current status, vulnerability contact, update period, communications matrix, secure initialization, log samples, EOL/EOS policy and FAT/SAT results. A copied logo or future-compliance statement is not enough.

Summary: connect Japan’s baseline to evidence in Thailand

The value of JC-STAR for overseas sites is not merely buying a product with stars. It is giving Japanese headquarters a product-security vocabulary while the Thai factory proves safe deployment in its real architecture and continuously monitors label state, firmware, vulnerabilities and support dates.

Verify the exact product and version, select an applicable level, define documentary evidence in the RFP, freeze the delivered item in FAT, exercise operational roles and real network paths in SAT, and monitor updates and exceptions after acceptance. Read mutual recognition within its stated scope and keep local compliance separate.

TOMAS TECH can support Thai factory IoT and OT projects from asset scoping and procurement requirements through communications, access design, FAT/SAT evidence and local operating procedures. You can contact us while you are still comparing products or drafting the RFP.

Primary sources

• IPA: JC-STAR
• IPA: Scheme details
• IPA: Application and reporting procedures
• IPA: How to verify a label
• IPA: Labeled product list
• IPA: JC-STAR adoption and mutual recognition
• IPA: UK PSTI mutual-recognition application
• METI: Launch of JC-STAR
• METI: Guide for IoT products in sector-specific systems
• METI: Japan–Singapore memorandum

*Scheme status, fees, recognition procedures and product records can change. This article reflects public information checked on 9 September 2026. Recheck IPA, METI and the relevant national authority immediately before procurement, application or legal determination.*