JC-STAR Network Equipment: Thailand Factory RFP, FAT and SAT Guide

When procuring JC-STAR network equipment for a factory in Thailand, selecting a router, managed switch or IoT gateway merely because it carries a label is not enough. The procurement record must connect the exact model and firmware, label validity, Japanese conformity record, any Thai NBTC requirements, FAT and SAT evidence, and responsibility for updates after handover.

This is not another overview of the scheme or a list of certified manufacturers. It is a practical Buy/Do guide for factories, system integrators, purchasing teams and IT/OT security owners comparing equipment for import into Thailand or local purchase. It explains the evidence to request in an RFP, the items to verify again at acceptance, and the compensating requirements to use when the proposed model is not listed.

Executive conclusion: buy a model–firmware–validity–local-conformity–ownership chain

A JC-STAR label is useful evidence, but it is not a blanket guarantee for an entire brand or product family. At minimum, procurement should freeze the following combination:

1. Manufacturer, product, exact model, SKU and hardware revision.
2. JC-STAR registration number, level and public page reached through the QR code.
3. Firmware covered by the registration and firmware actually delivered.
4. Label validity period and the method for checking expiration, cancellation or change.
5. Thai conformity for radio or telecommunications equipment, including NBTC as applicable, importer responsibility, marking and retained documents.
6. Named owners who recheck evidence at FAT, shipment, import, SAT and operational handover.
7. Operational rules for vulnerability response, firmware updates, configuration backup, replacement and retirement.

JC-STAR visualizes the cybersecurity conformity of IoT products under a Japanese scheme. It does not replace Thai radio and telecommunications conformity. Conversely, NBTC registration, certification or a Supplier’s Declaration of Conformity does not automatically satisfy a factory’s cybersecurity procurement requirements. Treat them as separate decision gates and do not approve the model until both evidence packages are complete.

The 2025–2026 JC-STAR timeline relevant to buyers

JC-STAR is designed to assess and make visible security functions in IoT products against criteria defined in Japan while taking account of international references such as ETSI EN 303 645 and NISTIR 8425. IPA began accepting Level 1 applications on 25 March 2025. From 22 April 2026, the method for obtaining an application number changed, with applicants directed to a dedicated form.

On 31 July 2026, IPA announced that a sharp rise in applications was making confirmation work take longer than usual. A procurement schedule should therefore avoid an unsupported promise that a pending application will be labeled by a fixed date. IPA also warns that an application is not guaranteed to be accepted or granted and restricts premature claims such as “JC-STAR compliant as planned.” A received number, provisional registration number and a granted label must not be treated as the same status.

The current update history on the IPA home page records publication of the Level 3 conformity requirements for communications equipment and network cameras, together with an update of related security requirements, on 12 June 2026. The entry for 5 June concerns requirements related to approval of conformity assessment bodies. RFP authors should pair dates with the actual document titles instead of copying a secondary headline.

Levels 1 and 2 use a self-declaration method based on a vendor’s assessment checklist against the defined criteria and procedure. Levels 3 and 4 rely on an evaluation report from an independent third-party assessment body. More stars do not automatically make a product suitable for every factory. The required level should reflect the deployment, trust boundary, business criticality, threat model and compensating controls.

Why this guide focuses on routers, switches and IoT gateways

Network equipment sits on trust boundaries: between machines and manufacturing systems, between a factory and a cloud service, and between production networks and remote maintenance. A poorly configured or unpatched router or gateway can affect a wider area than one failed sensor. The review needed for a switch also depends on whether it is managed, whether it contains radio functions, which ports are used and where it sits in the architecture.

Our broader guide to JC-STAR procurement for manufacturing explains how to incorporate the scheme into equipment purchasing. This article narrows the scope to model, firmware and acceptance evidence for routers, managed switches and IoT gateways. Read it together with our industrial network construction guide to keep product evidence separate from segmentation, redundancy, cabling and monitoring design evidence.

Five evidence checks for a JC-STAR labeled product

1. Treat the public register as the source of truth

A proposal, brochure or reseller page stating “supported” is not sufficient proof of a granted label. Open the IPA conformity-labeled product page and check the registration number, level, product, model, vendor, covered firmware, public validity information and route to security information. Record the URL and access date in the bid evaluation; do not preserve only a screenshot or brochure PDF.

2. Match the complete model string

Products with the same family name may use different radio modules, regional SKUs, power supplies, port layouts or hardware generations. Match the quotation, purchase order, package label, chassis nameplate and management interface using the exact model string. If a distributor omits a suffix, require the manufacturer to document the relationship.

3. Match the firmware condition

The label is not evidence about hardware alone. Read the firmware range, minimum or fixed version on the public record and obtain the delivered version from the management interface or command output. A unit that passed FAT can be substituted in storage, an RMA unit may arrive with an old image, and a factory reset may return it to another baseline. Recheck it at SAT and store the result in the asset register.

4. Check validity and current status

A record that was valid during tendering may change before a volume order, expansion or replacement. Requery it before purchase approval, at FAT, before shipment, at SAT and before repeat purchase. Use the QR code as a route to the live record, not as proof by itself.

5. Read the security and contact information

Check the vulnerability reporting channel, security advisory process, end of support, secure defaults, authentication, logs and update procedure. IPA explicitly notes that a label does not guarantee complete or perfect security. Unsafe configuration, exposed management services and weak credential handling can leave substantial risk in a labeled product.

What published examples teach about model and firmware specificity

An IPA public product page gives a registration example for NEC UNIVERGE IX-R2510, IX-R2520, IX-R2530 and IX-R2610 with firmware 1.5.1 or later and a note requiring use at Version 1.5 or later. Another page provides an example for amnimo G, R and X series with a firmware V3.4.0 condition.

These examples are not product endorsements. They show how a buyer should turn a family name into a verifiable configuration.

Do not collapse “firmware 1.5.1 or later” and “update to Version 1.5 or later for use” into a vague statement merely because they look similar. Read the current page, determine whether the delivered image is covered, choose the factory’s approved baseline, and assign the update task. Always obtain current data immediately before the final decision because public records can change.

Keep JC-STAR and Thai NBTC conformity as separate gates

A Japanese JC-STAR label does not replace conformity required to import, sell, install or operate radio and telecommunications equipment in Thailand. Depending on the device and use, review current NBTC technical standards, equipment classification, registration, certification or SDoC, spectrum and power conditions, marking and importer obligations.

The English reference translation of the Thai notification on conformity assessment categorizes relevant equipment into Class A, Class B and SDoC procedures. It addresses testing, registration or certification, retention of supporting documents, conformity marking and supplier responsibility after modifications. The translation also states that it is for comprehension and does not replace the Thai version. For a real procurement, confirm the current Thai text, equipment category, frequency and import scenario with a competent local owner or adviser.

Key distinctions include:

• A wired-only switch and a unit containing Wi-Fi, LTE/5G or LPWA functions do not have the same review scope.
• A Japan SKU and a Thailand SKU may differ in module, frequency, power supply and labels.
• Temporary import, evaluation use, commercial import and integration into production equipment may require different handling.
• Possession of a foreign test report does not by itself prove acceptance by NBTC.
• The model string in the JC-STAR record must be mapped to the model identified in the Thai conformity evidence.

Convert IoT security procurement criteria into an RFP

The RFP should make vendors answer against the same evidence. “Prefer JC-STAR certified” and “deliver the latest firmware” allow bidders to use incompatible assumptions. Split requirements into Must, Should, Evidence and Exception fields.

Recommended response matrix

Remove the term “latest firmware”

“Latest” changes over time and may not yet be validated with an OT application or driver. Require a reference date, approved version, minimum version, prohibited versions, relationship to the label, known vulnerability decision, update deadline and test method. If a new version appears before shipment, route it through change control instead of installing it automatically.

Define evidence freshness

Do not treat a submitted URL or certificate as permanently current. Put recheck points in the contract: within a defined period before purchase approval, before shipment and during SAT. Application volume, testing and import conditions may affect schedule and cost, so avoid unsupported standard lead times. Require each vendor to state assumptions, exclusions and dependencies.

Compensating requirements when the exact model is not listed

Absence from the register does not automatically mean rejection. It also cannot be replaced by one sentence saying that the manufacturer considers the device secure or that it follows an overseas standard. Combine controls in proportion to the use and impact:

1. Published secure-development and vulnerability-handling policy with a PSIRT contact.
2. Forced replacement of default passwords, strong administrator authentication and least privilege.
3. Disabled unnecessary services, isolated management plane, source restrictions and encrypted protocols.
4. Signed firmware, authenticity verification, rollback and recovery from failed update.
5. SBOM or component evidence and a committed vulnerability-impact response.
6. Audit logs, reliable time synchronization, external forwarding and retention.
7. Security-update support period, end-of-support date and advisory SLA.
8. Independent vulnerability assessment or penetration-test scope and executive result.
9. Factory segmentation, jump host, allowlisted communications and controlled remote maintenance.
10. If future labeling is contractual, valid application evidence and a remedy if the label is not granted.

Compensation is not a waiver. Record the residual risk, owner, approver and expiry date. Internet-edge routers, site-to-site VPN concentrators and gateways aggregating critical machines merit stronger independent assessment and configuration review. A good device test does not offset permanent vendor access or a shared administrator account.

FAT: freeze the pre-shipment evidence

FAT should establish that the contracted device, firmware and configuration exist—not merely demonstrate that traffic passes. Use the same model, hardware revision and firmware intended for delivery whenever possible.

Document review before FAT

• Reconcile the bill of materials, quoted model, quantity and radio module.
• Reopen the IPA page and capture registration number, level, firmware condition and validity.
• Confirm the applicable Thai classification, registration/certification/SDoC, importer and marking.
• Verify the firmware source, signature or hash procedure and release notes.
• Approve hardening, communication allowlist, administrator accounts and certificate issuance.

FAT tests on the device

1. Collect model, serial, hardware and firmware from the chassis and management interface.
2. Verify forced credential change, unnecessary services and approved management protocols.
3. Prove that unauthorized source networks cannot reach the management plane.
4. Generate failed-login, configuration-change, restart and update events and verify log export.
5. Test configuration backup, restore, update and safe rollback in a controlled setup.
6. Disconnect WAN or cloud access and observe degraded operation and resynchronization.
7. Compare captured traffic with the approved matrix and investigate undeclared destinations or ports.

The FAT package should include date, tester, serial number, screenshots or command outputs, baseline version, logs, exceptions and retest results. A pass/fail box alone cannot prove whether the unit delivered in Thailand is the unit tested.

Preserve the evidence chain through shipment and local purchase

For a unit tested in Japan and imported into Thailand, link each FAT record to a shipment serial number. Include model, serial, quantity and required conformity documents in the packing file and assign customs and importer responsibility contractually. Do not treat hand-carrying an evaluation unit and later converting it to production as an informal shortcut; confirm the correct handling for the intended use and import method.

For local procurement, do not order only the family name approved by headquarters. Verify the Thailand SKU, local conformity mark, warranty, delivered firmware and local RMA stock. “Equivalent product” must go back through model, feature, JC-STAR, NBTC, firmware and support review before approval.

SAT: close the real-site differences

SAT reconciles the FAT package to the delivered unit and then tests Thailand-site power, WAN, DNS, NTP, identity, monitoring, firewall, cloud connection and maintenance access.

If SAT requires a firmware change, do not reduce the decision to whether the new version remains inside the label condition. Put backup, signature check, compatibility, outage, rollback, event logs and regression tests in one change record. Cost and duration vary by model, connectivity, permitted downtime and test scope; obtain a project-specific estimate with explicit assumptions.

Operational handover: make conformity a lifecycle control

After acceptance, the factory needs a RACI and asset register showing who checks what and when. Avoid a state in which purchasing knows the registration URL but operations does not know the model and firmware conditions.

Minimum asset-record fields

• Asset ID, location, function, criticality and network zone.
• Manufacturer, product, model, SKU, hardware revision and serial.
• JC-STAR number, level, URL, validity and last-review date.
• Approved, running and prohibited firmware, update history and next review.
• Thai conformity number or classification, document location and importer.
• Management address and method, account owner and certificate owner.
• Configuration backup, restoration instructions, spare and RMA terms.
• PSIRT, support contact, EOL/EOS and advisory recipients.
• Exceptions, compensating controls, approver and expiry.

Firmware decision workflow

When an advisory arrives, determine whether the exact model and firmware are affected, whether the feature is enabled, whether it is reachable and what exploitation requires. Then select an emergency mitigation, validate the update, approve downtime, deploy it, verify function and update the register. Compatibility and configuration must be tested even when the version remains within the registered firmware condition.

Validity, support status and Thai requirements also need scheduled review. Always recheck before repeat purchase, RMA, firmware change, change of use or inter-factory transfer. Do not copy a historical approval without reevaluation.

Score evidence strength separately from residual risk

If tender scoring gives all weight to the label, a labeled product with short support or a Thailand-ineligible SKU may rank first. Separate the dimensions.

TCO should include local conformity work, testing, configuration, monitoring, updates, outages, spares, RMA and retirement, not only the purchase price. No universal price or lead time is defensible here. Compare quotations against the same quantities, radio features, import model, test depth, downtime and compatibility assumptions.

Common procurement failures and controls

Assuming that every model in a family is covered

Match the exact model, suffix, hardware revision and firmware. Attach the manufacturer mapping to the contract when necessary.

Keeping only an image of the QR label

Open the public page, verify number, level, model, firmware and validity, and retain the URL and access time.

Missing substitution after FAT

Link serial numbers to the shipment and repeat identification at SAT. Apply the same approval to RMA replacements.

Treating JC-STAR as Thai regulatory approval

NBTC and other local checks remain separate. Review radio functions, frequency, import scenario and local SKU under current rules.

Assuming that any newer firmware is automatically safer

Evaluate the conformity condition, vulnerability fix, compatibility, configuration migration and rollback separately. Control an approved version rather than the word “latest.”

Handing operations only a URL

Transfer the asset register, advisory route, update SOP, spare plan, exception expiry and RACI, and rehearse restoration and replacement.

FAQ: procuring JC-STAR network equipment

Can a JC-STAR labeled product be used immediately in a Thai factory?

No. JC-STAR does not replace Thai NBTC or other applicable local conformity. Review the exact model and firmware security record and separately confirm equipment class, import, registration/certification/SDoC, marking and Thailand SKU.

Should we always choose the product with more stars?

Choose according to use and risk. Levels 1/2 use self-declaration, while Levels 3/4 use third-party assessment. Architecture, configuration, operations, Thai conformity and support lifetime still affect suitability.

What firmware evidence is needed for an IoT gateway?

Record the registered condition, delivered version, approved factory baseline, prohibited versions, target update, signature check, compatibility and rollback. The amnimo G/R/X V3.4.0 example illustrates why family and firmware must be matched together.

What firmware applies to the NEC UNIVERGE IX-R2510 example?

The cited registration example covers IX-R2510/2520/2530/2610 with firmware 1.5.1 or later and includes guidance to update to Version 1.5 or later for use. Recheck the live IPA record and manufacturer information before ordering.

Must an unlisted model be rejected?

Not necessarily. Set compensating requirements for PSIRT, secure update, authentication, logs, SBOM, independent testing, segmentation and support duration, and obtain explicit residual-risk approval.

How should a “JC-STAR application pending” response be scored?

Distinguish it from a granted label and verify the type and basis of any IPA-issued number. Because IPA has reported confirmation delays, avoid an unsupported grant date and agree on substitutes, hold points or contractual remedies.

Do FAT and SAT need to repeat the same checks?

Yes. FAT freezes the pre-delivery configuration; SAT verifies the serial, firmware, local marking, network settings, logs and remote access of the unit actually installed. Transport, substitution and site changes otherwise break the evidence chain.

Is there a standard implementation cost or lead time?

No single figure is reliable. Model, quantity, radio functions, import path, test scope, permitted outage and existing architecture materially change both. Require a quotation with assumptions, exclusions, evidence and retest conditions.

Summary: connect procurement evidence to operations

For JC-STAR network equipment, verify the exact model, firmware condition, number, level, public QR destination and validity rather than a label image or family name. In Thailand, confirm NBTC and any other local conformity separately; JC-STAR does not replace it. Standardize the evidence in the RFP, freeze it at FAT, link shipment serials, recheck it in the operating environment at SAT, and transfer it into the asset register and update workflow.

TOMAS TECH can help before a preferred model is selected, from RFP evidence matrices and Thailand SKU review to FAT/SAT cases and operational registers. You are welcome to contact us while requirements are still being defined.

References

• IPA, “Cybersecurity Labeling Scheme (JC-STAR)”: scheme, assessment methods, 2026 update history and application-delay notice

https://www.ipa.go.jp/security/jc-star/index.html

• IPA, “New applications for Levels 1 and 2”: Level 1 intake started on 25 March 2025, and the application-number procedure changed on 22 April 2026

https://www.ipa.go.jp/security/jc-star/shinsei/shinki-1-2/index.html

• IPA, detailed information on JC-STAR

https://www.ipa.go.jp/security/jc-star/detail.html

• IPA, how to read and confirm a conformity label

https://www.ipa.go.jp/security/jc-star/label-description.html

• IPA, Level 1 conformity criteria and evaluation guides

https://www.ipa.go.jp/security/jc-star/tekigou-kizyun-guide/label1/index.html

• IPA, JC-STAR regulations and related requirements

https://www.ipa.go.jp/security/jc-star/kitei.html

• METI, policy background for the IoT product security conformity scheme

https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_cybersecurity/iot_security/20241106.html

• IPA public product record, NEC UNIVERGE IX-R2510/2520/2530/2610 example

https://jc-star.ipa.go.jp/conformance/CNF_019c788d-013b-731f-9eda-f539ae8e83a6.html

• IPA public product record, amnimo G/R/X series example

https://jc-star.ipa.go.jp/conformance/CNF_019b34a2-42c2-7280-aeae-5694c6f97c78.html

• NBTC, “Conformity Assessment of Telecommunication Equipment,” English reference translation

https://standard1.nbtc.go.th/getattachment/2583af14-e879-4b21-8295-5789f34492ec/e8001.aspx

*This article reflects public information checked on 2 September 2026 and provides general procurement guidance, not legal, customs or certification advice. Schemes, registrations, classifications and rules can change. Reconfirm current requirements with IPA, NBTC, other competent authorities and qualified advisers immediately before purchase, import and use.*