When a Thai factory installs or renews connected cameras, “it carries a JC-STAR label” is not a complete procurement requirement. Buyers must verify the exact model, conformant firmware range, current label validity and status, update mechanism, vulnerability contact, support term and the controls that will apply after connection to the plant network. This guide turns JC-STAR network camera selection into an auditable path from RFP and comparison through FAT/SAT and the first 90 days of operation. Procurement, IT, OT, engineering and quality can use the same evidence chain.
1. Why put JC-STAR network cameras in procurement requirements now?
Read the scheme’s current position accurately
JC-STAR is the IoT product security conformance assessment and labelling scheme operated by IPA under a framework developed by Japan’s Ministry of Economy, Trade and Industry. Level ★1 is a supplier self-declaration of conformance, while ★3 uses an independent third-party assessment. The stars should not be treated as a simple quality ranking. Buyers must distinguish the product scope, intended environment, assessment depth and their own procurement policy. The IPA scheme overview describes the purpose and structure.
The conformance-labelled product list, updated on 18 August 2026, includes multiple active ★1 camera and NVR products. A brand appearing on that list does not prove that the model and firmware in a quotation are covered. Open the conformance record for each candidate and reconcile model, firmware, registration number and status. Do not turn the list into an unsupported product count or market-share claim.
IPA published ★3 requirements for network cameras on 6 February 2026 and updated them on 12 June 2026, when conformance requirements were made available. The ★3 page says that the evaluation guide is still being prepared. An RFP therefore should not assume that a future ★3 label will be available for every purchase. Check what assessment information exists at the decision date and combine the available label check with additional product and operational due diligence.
Why a Japanese procurement baseline can still help a Thai plant
JC-STAR is a Japanese scheme, but it provides a common verification vocabulary for a Japanese headquarters, Thai subsidiary, installer, camera supplier and network team. All parties can refer to the same registration record and checklist. It does not replace Thai requirements. Privacy, surveillance, electrical, communications, cybersecurity, import and installation obligations must be reviewed for the specific project.
METI’s April 2026 material discusses higher-level criteria for communications equipment and network cameras. Mutual recognition with the UK PSTI began in January 2026. A memorandum with Singapore CLS was signed on 18 March 2026, and mutual recognition began on 1 June 2026. This is useful context for international sourcing, but it does not make every model automatically compliant with every scheme. Confirm the product scope, level, validity and conditions of recognition. See the METI material.
2. How should buyers verify the JC-STAR label and product list?
Convert the difference between ★1 and ★3 into a buying decision
Level ★1 is a supplier self-declaration against common minimum requirements. The ★1 checklist is version 5 May 2025 and was corrected on 29 June 2026. Record both the latest checklist version and the version of any evidence that a supplier used in its quotation.
Level ★3 adds threat-based requirements for a defined product class, such as network cameras, and uses an independent third-party assessment. Greater assessment depth does not configure the deployed system for the factory. Segmentation, identity administration, log monitoring and secure maintenance still need project-level acceptance. Product assessment and system acceptance are separate gates.
Preserve registration number, QR, validity and status as evidence
The label description explains the registration number, QR-based lookup and label validity period. Recheck the same information at RFP, purchase order, FAT and SAT, and retain a dated PDF or screen capture.
Treat these five checks as a single evidence set:
- The exact model in the quotation matches the conformance record.
- The delivered firmware is inside the conformant range.
- The registration number matches the QR destination.
- The label is valid and has an acceptable status at decision and acceptance dates.
- A procedure explains whether later firmware remains in scope and when to recheck.
An integrated camera conformance example, updated on 2 July 2026, specifies firmware 2.00 or later and warns that existing connections require a settings change. This is not a vendor recommendation. It demonstrates why the record must be read for model, firmware and connection conditions.
3. How do six gates turn JC-STAR procurement requirements into control?
Gates 1 to 3: scope, product capabilities and supplier commitment
Gate 1 is label conformance: model, firmware, registration number, validity and status. Gate 2 is product security capability: initial credentials, update, encryption, certificate handling, logs, time synchronisation, configuration backup and restoration. Gate 3 is supplier commitment: supported life, EOL notice, vulnerability intake, advisories, correction delivery and local or remote assistance.
Gates 4 to 6: architecture, verification and operational handover
Gate 4 is factory architecture: place cameras, recording, management, network services and logging in defined zones and allow only necessary flows. Gate 5 is FAT/SAT: map every requirement to a test, acceptance criterion, evidence and retest rule. Gate 6 is operations handover: assign ownership for accounts, update decisions, log review, backups, incident escalation and data erasure at disposal.
A single gate sheet lets procurement check technical disqualifiers before comparing price. It also prevents IT from judging only product specifications while engineering judges only whether a camera connects. Where existing plant wireless is involved, use the Thai factory wireless LAN design guide to design radio performance and security boundaries separately.
4. What belongs in an RFP for JC-STAR conformant products?
Mandatory conditions and response format
A free-form claim that a product is “supported” cannot be compared. Specify the response format and required attachments. Adapt the following baseline to the project.
| Area | RFP requirement | Supplier response and evidence | Acceptance rule |
|---|---|---|---|
| JC-STAR | Provide registration number, label level, validity and current status | Conformance URL and dated PDF | Exact model match |
| Model and firmware | Provide quoted model, regional SKU, delivery firmware and conformant range | BOM, device screen, release notes | Every unit traceable |
| Support | State security update term, EOL/EOS notice process and notice period | Published policy or contract term | Covers intended life |
| Vulnerability response | Identify intake, reporting process, advisory and emergency contact | PSIRT details, SLA or procedure | Owner and route clear |
| Initial configuration | Support unique initial values or first-use change and disable unused services | Configuration guide and FAT evidence | Baseline enforceable |
| Identity and roles | Support named users, RBAC, admin separation and lockout | Role matrix and screen evidence | No shared admin |
| Encryption and certificates | State methods for management, video and APIs, including renewal | Supported methods and settings | Only approved methods used |
| Updates | Explain signature checks, failure recovery, rollback conditions and offline update | Procedure and test record | Recoverability demonstrated |
| Logs and NTP | Provide authentication, configuration, update and fault logs, export and NTP | Event list and forwarding test | Time-aligned traceability |
| Backup | Explain export, protected storage, restore and model compatibility | Backup and restore test | Rebuild on replacement unit |
| Data | Map storage and erasure of recordings, snapshots and metadata | Data flow and erasure evidence | Meets retention policy |
| FAT/SAT | Accept the test and evidence table below | Plan, results and corrective-action log | No open issue unless approved |
Preserve change control in the contract
Firmware will change after purchase. The contract should allocate responsibility for advance notice, release content, security priority, compatibility checks, backup, staging, production approval and rollback. If an update may leave the stated JC-STAR range, the supplier should explain the impact and the buyer should recheck the conformance record.
For a deeper view of application and verification, see the JC-STAR application guide for 2026. Understanding the applicant’s evidence helps a buyer ask for the right artefacts.
5. Why should candidate products not be compared on the label alone?
Fill the comparison with Verified, Conditional and Unverified
Before scoring, classify the quality of evidence. Verified means primary information or device evidence exists. Conditional means the requirement depends on configuration or contract. Unverified means an answer is outstanding. Do not hide an important unknown inside an average score; make it a failed gate where appropriate.
| Comparison axis | Candidate A | Candidate B | Candidate C | Decision rule |
|---|---|---|---|---|
| JC-STAR model and firmware | Verified/Conditional/Unverified | Same | Same | URL, registration and firmware evidence required |
| Label validity | Same | Same | Same | Recheck at decision and acceptance |
| Update and recovery | Same | Same | Same | Test signature, failure and rollback |
| Vulnerability contact and SLA | Same | Same | Same | Check contract term and escalation |
| RBAC and accounts | Same | Same | Same | Verify named users and least privilege |
| Encryption and certificates | Same | Same | Same | Test protocols actually used |
| Logs and NTP | Same | Same | Same | Confirm external traceability |
| VMS/NVR interoperability | Same | Same | Same | Record and replay under target load |
| Support and EOL | Same | Same | Same | Fit operating and replacement horizon |
| FAT/SAT evidence | Same | Same | Same | Evidence for each requirement ID |
Compare price only among candidates that pass mandatory gates. Normalise quantity, licences, certificate operations, VMS/NVR, log retention, staging units, maintenance, updates, spares and secure disposal to compare total cost of ownership. This guide provides no fixed price or saving rate because quantity, retention, bandwidth and support scope differ by project.
The evidence register is not a one-time selection document. Update it when quotation responses arrive, when the order specification is frozen, before FAT, before shipment, during SAT, before and after firmware changes, and at the periodic review defined by the organisation. Record the requirement ID, asset, registration number, label-check date, source URL, firmware, evidence location, decision, open action, owner and next review date. Keep a dated PDF or screen capture because a URL alone does not preserve what was reviewed. Reopen the official record immediately before a decision because a capture alone cannot prove the current status.
Classify change requests as security correction, functional update, configuration change, replacement or network change. Record the reason, affected quantity, current and target firmware, impact on conformance scope, outage, backup, tests, rollback condition and approver. Even after an emergency correction, update the evidence register and inventory instead of leaving a temporary action as an undocumented permanent state. Evaluate the complete operating configuration because updating a camera can affect NVR/VMS or certificate interoperability.
Define a RACI model as well. Procurement owns contractual evidence and substitution control; IT or OT owns network and identity controls; engineering reconciles installed units; information security owns the baseline and exception approval; the supplier owns product information and correction; and the operating owner monitors and decides on updates. Adapt the role names, but assign one responsible and one accountable owner for every task, plus consultation and information paths. Include staff transfer, emergency delegation and out-of-hours contacts in handover.
An exception needs a reason, residual risk, compensating control, expiry, corrective-action owner and review date. If automated certificate renewal is unavailable, for example, use expiry monitoring and a manual renewal procedure as a temporary control and set a permanent remediation date. Review expired exceptions and close or reapprove them. This prevents an item labelled Conditional during evaluation from remaining indefinitely after go-live.
Set the review cadence by risk and volume of change. Immediately after go-live, review open corrections, log delivery, clock drift, account issuance, backup success and supplier advisories weekly. Move to a monthly or quarterly governance cycle only after stabilisation. Open an ad hoc review for a critical vulnerability, new firmware, an approaching certificate expiry, a network or NVR/VMS change, or a maintenance-contract change. Return the source-record date, affected requirement IDs, approved exceptions and next review dates to the evidence register.
Handover should be an operations pack, not a configuration guide alone. Include the asset list, zone diagram, allowed flows, account request, secret-storage location, certificate renewal, firmware staging, normal log state, backup restoration, fault isolation, supplier escalation, replacement and erasure. Ask the operations team to demonstrate log search, configuration restoration, account revocation and incident-ticket creation on a test unit or in an approved window. A procedure that cannot be demonstrated is not complete handover.
Evidence naming and storage also require control. Use searchable requirement ID, asset ID, test phase, date and version, and distinguish the latest working file from the approved record. Do not overwrite originals. Preserve the reason for change and approval history, and separate viewing from editing permissions. Months later, an update or replacement can then be traced back to the exact scope and evidence accepted at commissioning.
6. How should the factory network zones be designed at the same time?
Separate camera, recording, management, network and logging functions
A connected camera is not a standalone asset. Separate a camera zone, NVR/VMS recording zone, management workstation zone, network service layer and security logging layer. Allow only necessary flows at each boundary. Do not assume direct camera access to the internet; design time, name resolution, update distribution and monitoring paths. Remote maintenance should be approved, strongly authenticated, time-limited, logged and explicitly closed.
Use NIST and ETSI as dictionaries for missing controls
NIST IR 8259 Rev.1, revised in April 2026, organises foundational IoT product cybersecurity activities. NIST IR 8259A identifies six core capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. The NIST technical catalog and SP 800-213A expand this into seven classifications by adding Device Security. Use these as a completeness check, not as one-to-one equivalence with JC-STAR.
ETSI EN 303 645 V3.1.3 is another useful consumer-IoT baseline. Factory availability, long support, closed-network operation, recovery and evidence requirements usually add project-specific controls. The IPA network camera security explainer can also help stakeholders understand camera-specific exposure.
7. How does FAT/SAT turn JC-STAR procurement requirements into evidence?
Verify before shipment in FAT and in the actual site configuration in SAT
FAT checks delivery models and firmware, baseline configuration, accounts and RBAC, certificates, update and failure recovery, logs, NTP, backup/restore and VMS/NVR integration. SAT repeats applicable requirements on the Thai plant’s actual network, switches, NVR/VMS, logging platform and operational accounts. Passing FAT is not a reason to omit SAT.
| Requirement ID | FAT test | SAT test | Required evidence | Pass and retest rule |
|---|---|---|---|---|
| CS-01 | Reconcile model, firmware, registration and BOM | Reconcile every installed device and inventory | Conformance PDF, BOM, screen | Hold if any mismatch |
| CS-02 | Change initial secret and disable unused services | Confirm baseline on all devices | Config difference and screens | Correct and recheck all |
| CS-03 | Test named users, RBAC and lockout | Confirm production identity owners | Role matrix and audit logs | Fail if shared admin remains |
| CS-04 | Install certificate and verify encryption | Block plaintext and weak methods on real path | Packet and setting evidence | Exception requires expiry |
| CS-05 | Test normal update, failure and recovery | Confirm staging-to-production approval | Firmware, hash, logs, procedure | Fail if recovery unavailable |
| CS-06 | Export auth, config and update events | Confirm SIEM/syslog receipt and NTP | Sender/receiver logs, time check | Fix gaps and resend |
| CS-07 | Back up and restore to replacement unit | Confirm protected storage and routine restore | Backup and restore result | Resolve all differences |
| CS-08 | Record, replay and recover VMS/NVR | Test target load, power and link loss | Video, events and issue log | Agree limits and retest |
| CS-09 | Verify data erasure before shipment | Verify replacement and disposal evidence | Erasure process and form | Reconcile asset closure |
Keep the evidence chain intact
Manage the requirement ID, test, evidence, decision, correction and retest as one chain. A screenshot alone does not identify the unit, firmware, operator, time or procedure. Record asset number, serial, model, firmware, tester, date, environment, expected result and actual result. After a change, select affected requirement IDs and perform a controlled differential retest.
METI’s specific-field system guidance includes a factory-system example. It supports treating cameras as connected factory assets within risk management and operations, rather than as ordinary office supplies.
8. What is a practical 90-day implementation roadmap?
Days 0 to 30: freeze scope and requirements
Document purpose, monitored areas, recording scope, retention, authorised users, camera count, NVR/VMS, connectivity, existing network, logs and maintenance model. Retrieve JC-STAR records for candidates and verify firmware range and validity. Name owners across procurement, IT, OT, engineering, privacy/legal and quality. Freeze the RFP and acceptance requirement IDs.
Days 31 to 60: evaluate candidates and perform FAT
Compare supplier responses as Verified, Conditional or Unverified and resolve important unknowns. Test accounts, RBAC, certificates, updates, logs, NTP, backups and VMS/NVR with real devices. Link each FAT defect to a corrective action. For any exception, record expiry, owner, residual risk and closure condition.
Days 61 to 90: complete SAT and operational handover
After installation, verify zones, ACLs, operational accounts, logs, NTP, recording, power recovery, link loss and backup restoration. Register model, serial, firmware, registration number, location, owner, support and EOL in the asset inventory. Transfer the update calendar, vulnerability escalation, periodic review and secure disposal procedure. Do not close the project with unowned actions.
| Period | Primary deliverables | Exit condition |
|---|---|---|
| Days 0–30 | Scope, data flow, RFP, requirement IDs, conformance records | Owners approve requirements |
| Days 31–60 | Candidate comparison, FAT plan/results, actions, change control | No critical unknown remains |
| Days 61–90 | SAT, asset inventory, baseline, operations/disposal procedures | Evidence and ownership handed over |
9. What common failures should a buyer avoid?
Treating the label as a complete safety guarantee
The label is an important indication of conformance within a stated scope, not a promise of zero risk or secure deployment. Reconcile model, firmware and validity, then test architecture and operations separately.
Deciding at brand level
Models, regional SKUs and firmware differ within one brand. Trace each unit at quotation, order, delivery, FAT and SAT. Do not approve substitutions verbally.
Ending firmware governance with “included in maintenance”
Define who receives advisories, where updates are staged, who approves production and how failure is reversed. Recheck the conformant range when firmware changes.
Connecting cameras directly to the existing LAN
Available bandwidth does not make the architecture secure. Separate camera, recording, management and logging functions, list allowed flows, and control remote support and internet access.
Copying FAT evidence into SAT
Switches, ACLs, time, certificates, identities, VMS/NVR and power behaviour differ on site. Execute SAT in the real configuration and preserve the differences.
10. FAQ: Questions about JC-STAR network camera procurement
Q1. Is a JC-STAR conformant network camera safe?
It is not a complete safety guarantee. Verify model, firmware, validity and status, then test initial settings, RBAC, encryption, logs, NTP, updates, segmentation and backup in the deployed architecture.
Q2. Should an RFP require ★1 or ★3?
That depends on available assessments, use environment, risk and policy. ★1 is self-declaration; ★3 is independent third-party assessment. Check the current ★3 publication status and add project controls regardless of level.
Q3. Is checking a brand name enough for a JC-STAR conformant product?
No. Check exact model, regional SKU, delivery firmware, conformant firmware range, registration, validity and status. Review any substitute model again.
Q4. What are the minimum JC-STAR procurement requirements?
Include support term, EOL, vulnerability contact, update and recovery, initial configuration, identity/RBAC, encryption and certificates, logs and NTP, segmentation, backup/restore, data erasure and FAT/SAT evidence in addition to label data.
Q5. Should an existing camera fleet be replaced immediately?
Start with inventory and risk assessment. Review model, firmware, external exposure, update capability, authentication, logs, network position and support expiry, then prioritise configuration, segmentation, update and replacement.
Q6. Does using JC-STAR make a Thai factory compliant with Thai law?
No. JC-STAR can support a shared product-security baseline, but Thai privacy, surveillance, communication, installation and related obligations require separate review.
Q7. Does conformance automatically continue after a firmware update?
Do not assume so. Recheck the firmware range, supplier information and current status, and preserve pre-change and post-change test evidence.
Q8. What should FAT/SAT verify first?
First reconcile BOM, unit, model, firmware and registration. Then test initial settings, RBAC, encryption, update and recovery, logs and NTP, backups, NVR/VMS and segmentation by requirement ID.
Q9. When should price be compared?
Compare price among candidates that pass mandatory gates, using the same quantity, configuration, support, retention, testing, spare and disposal assumptions. A low price should not offset an important unknown.
11. Conclusion: Procure the operating model, not only the label
The key to JC-STAR network camera procurement is to use the label as a verifiable starting point. Confirm model, firmware and validity, then link product capabilities, supplier commitment, factory zones, FAT/SAT evidence and operational responsibility. Distinguish ★1 self-declaration from ★3 independent assessment, and never omit deployment and lifecycle controls.
TOMAS TECH can assist from existing-camera inventory and RFP preparation through candidate comparison, network segmentation and FAT/SAT design. If you want to define requirements and evidence before choosing a product, contact TOMAS TECH.
References
- IPA: JC-STAR overview
- IPA: JC-STAR conformance-labelled product list
- IPA: ★1 criteria and guide
- IPA: Network camera ★3 criteria and guide
- IPA: JC-STAR label description
- IPA: Integrated camera conformance example
- METI: April 2026 JC-STAR material
- METI: Cybersecurity guidance for factory systems
- NIST IR 8259 Rev.1
- NIST IR 8259A
- ETSI EN 303 645 V3.1.3
- IPA: Network camera security
