JC-STAR สำหรับฐานต่างประเทศ: RFP และ FAT/SAT โรงงานไทย

เมื่อสำนักงานใหญ่ญี่ปุ่นต้องการใช้ JC-STAR ในฐานการผลิตต่างประเทศ ประเด็นแรกที่ต้องตกลงให้ชัดคือ ฉลากของญี่ปุ่นไม่ได้เป็นหลักฐานว่าผลิตภัณฑ์ผ่านข้อกำหนดของประเทศไทยโดยอัตโนมัติ คุณค่าที่ใช้งานได้จริงคือการใช้ JC-STAR เป็นเส้นฐานร่วมของเกณฑ์จัดซื้ออุปกรณ์ IoT ด้านความปลอดภัย แล้วแปลงเส้นฐานนั้นเป็นข้อกำหนด RFP หลักฐานการคัดเลือกผู้ขาย การทดสอบ FAT/SAT และการติดตามอัปเดตหลังเริ่มใช้งานจริงในโรงงานไทย

สรุปสำหรับผู้บริหาร: เปลี่ยนฉลาก JC-STAR ให้เป็นหลักฐานการตรวจรับหน้างาน

JC-STAR เป็นโครงการติดฉลากภาคสมัครใจของญี่ปุ่น ครอบคลุมผลิตภัณฑ์ IoT หลากหลายชนิดที่รับส่งข้อมูลด้วย IP ระดับ ★1 กำหนดข้อกำหนดพื้นฐานขั้นต่ำร่วมกัน ระดับ ★2 ขึ้นไปเพิ่มข้อกำหนดตามประเภทผลิตภัณฑ์และระดับความน่าเชื่อถือ ★1 และ ★2 ใช้การประกาศความสอดคล้องโดยผู้ขายและ IPA เป็นผู้ออกฉลาก ส่วน ★3 และ ★4 ต้องมีการประเมินโดยบุคคลที่สามที่เป็นอิสระ

อย่างไรก็ตาม ฉลากที่ยังมีผลไม่ได้พิสูจน์ว่าอุปกรณ์ถูกติดตั้งและใช้งานอย่างปลอดภัยในโรงงานไทย IPA อธิบายชัดว่าการมีฟังก์ชันความปลอดภัยกับการใช้งานฟังก์ชันนั้นอย่างปลอดภัยต่อเนื่องไม่ใช่เรื่องเดียวกัน โรงงานยังต้องรับผิดชอบการแบ่งเครือข่าย การตั้งค่าเริ่มต้น สิทธิ์ผู้ใช้ Log การสำรอง การรับแจ้งช่องโหว่ การแจกจ่ายอัปเดต การสิ้นสุดการสนับสนุน และการลบข้อมูลเมื่อเลิกใช้

ดังนั้น มาตรฐานจัดซื้อของสำนักงานใหญ่ควรแบ่งเป็นสองชั้น ชั้นแรกถามว่ารุ่นและเวอร์ชันที่ซื้ออยู่ในขอบเขตฉลาก JC-STAR ที่เหมาะสมและยังมีผลหรือไม่ และตรวจสอบในหน้าข้อมูลผลิตภัณฑ์ของ IPA ได้หรือไม่ ชั้นที่สองถามว่าอุปกรณ์ติดตั้ง เชื่อมต่อ ใช้งาน อัปเดต กู้คืน และเลิกใช้อย่างปลอดภัยภายใต้สถาปัตยกรรมจริงของโรงงานไทยได้หรือไม่ พร้อมมีหลักฐานจาก FAT และ SAT ฉลากคือประตูเข้า ส่วนหลักฐานตรวจรับและการติดตามตลอดวงจรชีวิตคือสิ่งที่ทำให้การควบคุมสมบูรณ์

ขอบเขตห้าข้อที่มักเข้าใจผิดเมื่อใช้ JC-STAR ในโรงงานไทย

1. โครงการสมัครใจของญี่ปุ่นไม่ใช่ใบอนุญาตตามกฎหมายไทย

การเลือกผลิตภัณฑ์ที่มีฉลากช่วยให้บริษัทญี่ปุ่นกำหนดมาตรฐานข้ามประเทศได้สม่ำเสมอ แต่ไม่ได้ทำให้ผ่านข้อกำหนดไทยด้านความมั่นคงไซเบอร์ โทรคมนาคม วิทยุ การนำเข้า ข้อมูลส่วนบุคคล ความปลอดภัยอุตสาหกรรม หรือข้อกำหนดลูกค้าโดยอัตโนมัติ สิ่งที่ต้องใช้จริงขึ้นกับหน้าที่ของผลิตภัณฑ์ การเชื่อมต่อ ข้อมูลที่ประมวลผล และบริบทของโรงงาน

ใน RFP ควรเขียนว่า JC-STAR เป็นเกณฑ์ร่วมภายในกลุ่มบริษัท ไม่ใช่สิ่งทดแทนการตรวจสอบกฎหมายท้องถิ่น กำหนดเจ้าของงานระหว่างฝ่ายกฎหมายในไทย IT/OT วิศวกรรม ความปลอดภัย ข้อมูลส่วนบุคคล SI ท้องถิ่น และผู้ผลิตก่อนเปิดประมูล เพื่อลดความเสี่ยงพบใบอนุญาตหรือข้อกำหนดลูกค้าที่ขาดอยู่ในช่วงก่อนตรวจรับ

2. ฉลากครอบคลุมผลิตภัณฑ์ ไม่ใช่ระบบโรงงานทั้งชุด

IPA กำหนดวัตถุของฉลากเป็นผลิตภัณฑ์ IoT ที่เป็นหน่วยซื้อขาย หรืออุปกรณ์ร่วมกับบริการประกอบที่จำเป็น ปัจจุบัน “ระบบ” ทั้งระบบไม่ได้อยู่ในขอบเขต กล้องเครือข่ายที่มีฉลากไม่ได้แปลว่า VMS, Cloud, VPN, Switch, ระบบตัวตน, Notebook ช่าง, สายสัญญาณ การตั้งค่า และการเฝ้าระวังทั้งหมดผ่านการรับรอง

ทะเบียนทรัพย์สินควรผูกหมายเลขฉลากกับผู้ผลิต ชื่อสินค้า รุ่นจำหน่าย SKU ของภูมิภาค Hardware Revision, Firmware, บริการที่จำเป็น จุดติดตั้ง Network Zone และเจ้าของระบบ หากรหัสท้ายรุ่นหรือรุ่นสำหรับเอเชียต่างจากที่แสดง ต้องยืนยันขอบเขตจากหน้าผลิตภัณฑ์ IPA และเอกสารจากผู้ถือฉลาก

3. การกำหนดจำนวนดาวสูงสุดไม่ใช่คำตอบเสมอไป

★1 เป็นเส้นฐานร่วม ส่วน ★2 ขึ้นไปพิจารณาลักษณะของแต่ละประเภทผลิตภัณฑ์ เกณฑ์จึงอาจต่างกันแม้อยู่ระดับเดียวกัน หาก RFP บังคับระดับที่ยังไม่มีสำหรับประเภทนั้น อาจไม่มีผู้เสนอราคาหรือเกิดคำโฆษณาที่คลุมเครือว่า “พร้อมรองรับ”

ก่อนกำหนดเงื่อนไข ต้องตรวจว่าผลิตภัณฑ์อยู่ในขอบเขตหรือไม่ เกณฑ์ของประเภทนั้นเริ่มใช้งานแล้วหรือไม่ และระดับใดขอได้จริง ณ วันที่จัดซื้อ จากนั้นจึงกำหนดว่าเป็นข้อบังคับ คะแนนเพิ่ม แผนในอนาคต หรือยอมรับหลักฐานทดแทนที่ระบุชัด ห้ามให้ “เตรียมยื่น”, “อยู่ระหว่างยื่น” หรือ “JC-STAR Ready” มีค่าเท่าฉลากที่ออกแล้ว IPA เตือนไม่ให้แสดงข้อความที่ทำให้ผู้ซื้อเข้าใจว่าผลิตภัณฑ์ที่ยังไม่ได้ฉลากได้รับหรือมีแนวโน้มได้รับฉลากแล้ว

4. Mutual Recognition ไม่ใช่พาสปอร์ตทั่วโลก

ณ วันที่ 9 กันยายน 2026 ขั้นตอนการยอมรับร่วมกันภายใต้กฎหมาย UK PSTI เริ่มใช้ตั้งแต่ 1 มกราคม 2026 ผลิตภัณฑ์ที่สอดคล้อง PSTI และยื่น JC-STAR ★1 สามารถได้รับการยอมรับในเกณฑ์ JC-STAR สามข้อ และ IPA ระบุค่าธรรมเนียม 140,000 เยนรวมภาษี เทียบกับค่าปกติ 198,000 เยน ในทิศทางกลับกัน ผู้ถือ JC-STAR ที่ต้องการหลักฐาน PSTI ต้องยื่นเพิ่ม จัดทำข้อมูลผลิตภัณฑ์และช่องโหว่เป็นภาษาอังกฤษ และ IPA ระบุค่าดำเนินการเพิ่ม 5,500 เยนรวมภาษี

IPA ยังเผยแพร่ขั้นตอนที่เกี่ยวข้องกับ Singapore Cybersecurity Labelling Scheme หลังบันทึกความร่วมมือเดือนมีนาคม 2026 การยอมรับร่วมทุกกรณีจำกัดตามโครงการ ทิศทาง เกณฑ์ทางเทคนิค ขอบเขตผลิตภัณฑ์และขั้นตอน ไม่ได้แปลว่าข้อกำหนดของอีกประเทศผ่านทั้งหมด และไม่ใช่การยอมรับร่วมกับประเทศไทย ตารางจัดซื้อจึงควรแยกชื่อโครงการ ทิศทาง เกณฑ์ที่ยอมรับ เอกสารเพิ่ม ค่าใช้จ่าย และอาณาเขต

5. การที่ฉลากยังมีผลไม่ได้ทำให้การติดตามอัปเดตหมดความจำเป็น

ฉลากมีอายุ และรายการ IPA แสดงสถานะเช่น มีผล ช่วงผ่อนผันระหว่างต่ออายุ หมดอายุ ถอนโดยสมัครใจ หรือถูกเพิกถอน หน้าขั้นตอนปัจจุบันระบุว่าฉลากใหม่มีอายุสูงสุดสองปีนับจากออก โดยไม่ขึ้นกับระดับ ดังนั้น PDF ที่เก็บตอนซื้อไม่ใช่หลักฐานถาวร

สัญญาควรระบุช่องทางรับแจ้งช่องโหว่ ระยะเวลาให้ Security Update กำหนดแจ้ง วิธีอัปเดต การหมดอายุหรือถอนฉลาก ช่องโหว่ร้ายแรง เครื่องทดแทน Rollback และค่าแรงหน้างาน สำนักงานใหญ่ควรตรวจข้อมูลทะเบียน IPA เป็นรอบ ส่วนโรงงานไทยตรวจ Firmware และ Configuration จริงกับทะเบียนทรัพย์สิน

โมเดลสองชั้นสำหรับเกณฑ์จัดซื้ออุปกรณ์ IoT ด้านความปลอดภัย

อย่ารวมหลักฐานผลิตภัณฑ์กับหลักฐานหน้างานในช่องเดียว หลักฐานชั้นแรกมาจากผู้ขายผลิตภัณฑ์ ส่วนชั้นที่สองเกิดจาก SI และโรงงานร่วมกัน

ชั้นผลิตภัณฑ์ต้องยืนยันว่า QR หรือ URL ของฉลากไปยังหน้าที่ IPA ดูแล IPA แนะนำให้ตรวจ URL ที่ขึ้นต้น https://jc-star.ipa.go.jp/conformance/ รูปโลโก้ที่คัดลอกลง Proposal ไม่เพียงพอ

ชั้นโรงงานต้องตรวจว่าอนุญาตเฉพาะการสื่อสารที่ออกแบบ ปิด Service ที่ไม่จำเป็น ตั้ง Credential แยกรายอุปกรณ์ แยกเส้นทาง Admin และส่งออก Event ได้ อุปกรณ์ที่มีฟังก์ชันดีแต่ใช้รหัสเริ่มต้น เปิดทุกพอร์ต มี Vendor VPN ตลอดเวลา และไม่มีเจ้าของอัปเดต ไม่บรรลุวัตถุประสงค์จัดซื้อ

สำหรับภาพรวมสถาปัตยกรรม อ่าน คู่มือ OT Security สำหรับโรงงานในไทย และ การติดตั้ง IoT ในโรงงานต่างประเทศ หากรับผิดชอบการยื่นโครงการโดยตรง ให้ดู คู่มือสมัคร JC-STAR ปี 2026 ส่วนการค้นหาผู้ผลิตและรุ่นให้ดู การจัดซื้ออุปกรณ์ IoT ที่ได้รับ JC-STAR บทความนี้ไม่ทำซ้ำขั้นตอนกรอกใบสมัครหรือรายการผลิตภัณฑ์ แต่เน้นการแปลงนโยบายสำนักงานใหญ่สู่ RFP, FAT/SAT และ Update Monitoring

เขียน RFP สำหรับโรงงานอย่างไร: แยก Requirement, Answer และ Evidence

หลีกเลี่ยงคำถาม Yes/No ว่า “รองรับ JC-STAR หรือไม่” ให้ผูกทุก Requirement กับคำตอบผู้ขาย หลักฐาน จุดตรวจ และวิธีจัดการเมื่อไม่ผ่าน

ข้อ RFP 1: รุ่นที่เสนอเป็นรุ่นเดียวกับขอบเขตฉลาก

ให้เสนอผู้ผลิต ชื่อสินค้า รุ่นที่จำหน่าย SKU ภูมิภาค Hardware/Firmware บริการประกอบ หมายเลขทะเบียน ระดับ วันหมดอายุ และ URL IPA ของทุกอุปกรณ์ พร้อมเหตุผลว่าชุดที่เสนออยู่ในขอบเขต หลักฐานต้องมีหน้าข้อมูล IPA ป้ายรุ่น ตารางเวอร์ชัน BOM และแผนภาพ ไม่พึ่งคำรับรองตัวแทนเพียงอย่างเดียว

ข้อ RFP 2: ระดับที่ใช้ได้และ Gap

ให้ระบุเฉพาะระดับที่ออกแล้ว ณ วันเสนอราคา หากระดับที่ขอไม่มีสำหรับประเภทผลิตภัณฑ์ ต้องชี้แจงและ Mapping การควบคุมทดแทนกับหลักฐาน ใช้เกณฑ์ IPA ปัจจุบัน Checklist ขอบเขตรายงานภายนอก และใบอนุมัติข้อยกเว้น แยก Roadmap ออกจากหลักฐานที่ออกแล้ว

ข้อ RFP 3: Authentication และ Secret

ต้องตั้ง Credential แยกรายอุปกรณ์หรือ Enrollment ที่ปลอดภัย ห้าม Universal Default Password อธิบาย First Boot การเปลี่ยนเครื่อง Factory Reset การเปลี่ยนเจ้าของ และ Secret Rotation หลักฐานได้แก่หน้าตั้งค่า API Log การลงทะเบียน การสาธิตจาก Factory State และ Configuration Export ที่ไม่เปิดเผย Secret

ข้อ RFP 4: ช่องโหว่และ Security Update

ระบุช่องทางรายงาน ภาษา Response Target วิธี Advisory ระยะเวลา Update การลงนามและตรวจความถูกต้อง เส้นทางแจกจ่าย Offline Update การควบคุม Rollback Emergency Update และ Recovery หลักฐานคือ Disclosure Policy, Support Period ที่มีวันหรือสูตรชัด, Signature Log, Package ตัวอย่าง และ Advisory ในอดีต คำว่า “รองรับระยะยาว” ไม่ใช่กำหนดเวลา

ข้อ RFP 5: การสื่อสาร Log และเวลา

ประกาศ Destination, Protocol, Port, DNS, Certificate, Cloud Dependency และ Remote Maintenance ทุกเส้นทาง ต้องส่งออก Event ของ Login, Configuration, Update, Admin และการสื่อสารผิดปกติ โดยอ้างอิง Time Source โรงงาน หลักฐานคือ Communication Matrix, Packet Capture, Log ตัวอย่าง การตั้งเวลา พฤติกรรมเมื่อ Cloud ขาด และนโยบายเก็บ/ลบข้อมูล

ข้อ RFP 6: Supply Chain และ Change Notification

ผู้ขายต้องแจ้งเมื่อ Software Component, Third-party Cloud, Outsourced Maintenance, Firmware, End of Sale หรือ End of Support อาจกระทบ Security หรือสถานะฉลาก ส่ง SBOM หรือทะเบียนส่วนประกอบ กระบวนการเปลี่ยน ตัวอย่าง EOL/EOS Notice และ Reassessment Flow จุดหมายไม่ใช่แค่ “มีไฟล์ SBOM” แต่ต้องหาเครื่องที่ได้รับผลเมื่อพบช่องโหว่ได้

เปรียบเทียบวุฒิภาวะของหลักฐาน ไม่ใช่เพียงมี/ไม่มีฉลาก

ตารางเปรียบเทียบควรมีอย่างน้อยเจ็ดแกน ได้แก่ ความแท้และอายุฉลาก ความเหมาะสมของระดับ ความสามารถอัปเดต ความมองเห็นในการปฏิบัติการ การสนับสนุนไทย/อังกฤษ วงจรชีวิต และความสามารถทดสอบ แต่ละข้อกำหนดเป็น Must, Scored หรือ Exception-Controlled

อุปกรณ์ราคาต่ำที่ต้องให้ช่างต่างประเทศเดินทางทุกครั้งเมื่ออัปเดต หยุดทำงานหาก Cloud ปิด ส่ง Log ไม่ได้ และไม่แจ้ง EOL อาจมี Total Cost สูงกว่า ในทางกลับกัน การบังคับ Control ที่ไม่สัมพันธ์กับ Risk ของโรงงานเพิ่ม Lead Time และภาระโดยไม่เพิ่มความปลอดภัย

FAT: ล็อกผลิตภัณฑ์และหลักฐานก่อนส่งมอบ

FAT-1 ตรวจฉลากกับ BOM ส่งมอบ

เทียบ Purchase Order, Delivery BOM, กล่อง, Nameplate และ Model/Version ในหน้าจอ หาก Cloud Plan เป็นส่วนจำเป็นของขอบเขต ต้องอยู่ในสัญญา หาก SKU ภูมิภาคหรือโมดูลวิทยุต่าง ต้องมีคำยืนยันผู้ถือฉลาก

FAT-2 การเริ่มต้นที่ปลอดภัย

เริ่มจาก Factory State ทำ Enrollment ปิด Account ที่ไม่จำเป็น ตั้ง Least Privilege ลง Certificate และ Backup ทดสอบสองเครื่องเพื่อยืนยันว่าไม่ใช้ Secret เดียวกัน และ Factory Reset ไม่เหลือข้อมูลเจ้าของเดิม

FAT-3 วัด Allowlist การสื่อสาร

เทียบ Communication Matrix กับ Packet Capture ค้นหา DNS, NTP, Analytics, Telemetry หรือ Remote Support ที่ไม่แจ้ง ทดสอบเมื่อเข้า Cloud ไม่ได้ สำหรับ Encryption ให้ตรวจ Peer Authentication, Certificate Expiry, Revocation และ Re-enrollment ไม่ใช่แค่มี TLS

FAT-4 Update, Tamper และ Rollback

ทดสอบ Package ปกติ ลายเซ็นผิด การส่งขาด พื้นที่ไม่พอ และ Package ไม่เข้ากัน อุปกรณ์ต้องปฏิเสธ Code ที่ไม่ได้รับอนุญาต อยู่หรือกลับสู่ Safe State และสร้าง Log หาก Rollback ได้ ต้องป้องกันการลดรุ่นกลับไป Firmware ที่ทราบว่ามีช่องโหว่โดยไร้การควบคุม

FAT-5 Log และ Tabletop ช่องโหว่

สร้างเหตุ Login Admin ล้มเหลว เปลี่ยนค่า เปลี่ยนเวลา Update, Reboot และ Certificate Error ส่ง Log ไปปลายทางจริง ใช้ Advisory สมมติฝึกแจ้ง Vendor–สำนักงานใหญ่–โรงงาน–SI ค้น Asset ที่ได้รับผล กำหนด Compensating Control และตัดสิน Patch

ผลทุกข้อควรมี Test ID, Requirement ID, Serial, Version, Precondition, Action, Expected, Actual, Evidence, Deviation, Owner และ Due Date ลายเซ็น “ผ่าน” อย่างเดียวไม่สามารถสร้างคำตัดสินซ้ำภายหลัง

SAT: ตรวจรับในเครือข่ายและการทำงานจริงของโรงงานไทย

SAT-1 Zone และ Reachability

ใช้ VLAN, Firewall, DMZ, Jump Host และ VPN จริง ยืนยันว่าเส้นทางอนุมัติเท่านั้นที่ผ่าน ตรวจ Direct Internet จาก Production, Always-on Vendor Tunnel, Shared Maintenance PC และ Admin Port บน Business LAN ข้อยกเว้นชั่วคราวต้องมีเจ้าของ วันหมดอายุ และเงื่อนไข Monitor

SAT-2 วงจรชีวิต Identity ท้องถิ่น

สร้าง Role ให้ Operator ไทย Maintenance, External SI, Auditor และ Admin ญี่ปุ่น ใช้ MFA การอนุมัติ Emergency Account การทบทวนสิทธิ์ และปิดสิทธิ์เมื่อย้าย/ลาออก Runbook ภาษาญี่ปุ่นอย่างเดียวไม่ใช่การควบคุมที่ทำงานจริงในไทย

SAT-3 ไฟฟ้า WAN, DNS/NTP และ Cloud ขัดข้อง

ภายในขอบเขตที่ปลอดภัย จำลองไฟดับ Network ขาด DNS/NTP ขาด และ Cloud ใช้ไม่ได้ สังเกต Safe Production, Local Continuation, Data Gap, Restart Order, Time Drift และ Reauthentication ความปลอดภัยต้องไม่ทำให้ Availability หายโดยไม่จำเป็น และการป้องกันต้องไม่หายเงียบเมื่อเกิด Fault

SAT-4 อัปเดตผ่านกระบวนการบำรุงรักษาจริง

อัปเดตด้วย Bandwidth, Proxy, Approval และ Maintenance Window จริง หากทำจากญี่ปุ่น ต้องกำหนด Local Safety Check, Permit to Work, Abort Criteria และ Recovery Owner หลังอัปเดตตรวจ Firmware, Configuration Diff, Communication, Log และ Control Function อีกครั้ง

SAT-5 ส่งมอบหลักฐานและฝึกทีมท้องถิ่น

สำนักงานใหญ่และโรงงานรับร่วมกันทั้ง Asset Inventory, Network Diagram, Communication Matrix, Account, Backup, Update Procedure, Vulnerability Contact, EOL List และ FAT/SAT Evidence เจ้าของท้องถิ่นต้องสาธิตรับ Alert ระบุเครื่อง แยกเบื้องต้น และส่งหลักฐานที่ใช้ได้ให้ผู้ขาย

ใส่ Update Monitoring ไว้ในสัญญา

หลัง Go-live ให้ติดตามการเปลี่ยน ไม่ใช่แค่วันหมดอายุฉลาก รายเดือนตรวจ Firmware จริง ช่องโหว่ Vendor Notice และ Update ค้าง รายไตรมาสตรวจสถานะ IPA, Support Period, Privileged Account, Destination และ Exception รายปีฝึก Recovery, Escalation, เปลี่ยนผู้ขาย และ Disposal

แบ่ง Change เป็นสามกลุ่ม: Routine Change ใช้ขั้นตอนมาตรฐาน; Security-significant Change เช่น Authentication, Encryption, Destination, Cloud หรือกลไก Update ต้องทำ FAT หรือ SAT เฉพาะส่วนอีกครั้ง; Conformity-impacting Change ที่อาจกระทบ Self-declaration ต้องถามผู้ถือฉลากและเก็บหลักฐานว่าต้องแจ้ง ถอน หรือยื่นใหม่หรือไม่

เมื่อมีช่องโหว่ อย่าตัดสินจาก CVSS อย่างเดียว ให้ประเมิน Reachability, Prerequisite, ผลต่อ Control และ Safety, Compensating Control และความเป็นไปได้ในการ Patch หาก Patch ทันทีไม่ปลอดภัย ต้องกำหนด Traffic Restriction, ปิด Feature, Rotate Credential หรือ Enhanced Monitoring พร้อมเจ้าของและวันหมดอายุ

จัดการข้อยกเว้นสำหรับอุปกรณ์เฉพาะทาง

Gateway ของเครื่องเก่า อุปกรณ์เฉพาะ Lead Time ยาว หรือ SKU ต่างประเทศอาจไม่มีตัวเลือกติดฉลาก ข้อยกเว้นด้วยวาจาทำลายมาตรฐาน แบบฟอร์มต้องมีผลิตภัณฑ์ จุดติดตั้ง หน้าที่ ข้อมูล Network ที่เข้าถึง เหตุผลและวันที่สำรวจตลาด หลักฐานทดแทน การแบ่ง Zone/Allowlist/Monitor แผนอะไหล่และเปลี่ยน Residual Risk ผู้อนุมัติ วันหมดอายุ และวันทบทวน

ผูกวันหมดอายุกับ Planned Shutdown, End of Support หรือวันที่คาดว่าจะมีสินค้าทดแทน ติดตามข้อยกเว้นเปิดและเกินกำหนดที่สำนักงานใหญ่ เพื่อไม่ให้การอนุมัติชั่วคราวกลายเป็นสถาปัตยกรรมถาวรที่ซ่อนอยู่

แผน 90 วันสำหรับสำนักงานใหญ่และโรงงานไทยหนึ่งแห่ง

วันที่ 0–30: กำหนด Scope และ Baseline

ตั้งเจ้าของใน Procurement, Cybersecurity, Plant IT/OT, Engineering, Quality และ Local SI ทำ Inventory อุปกรณ์ IP แบ่ง JC-STAR Scope, Label, Criticality, Updateability และ EOL ออก RFP Template และ Exception Form และกำหนดหน้าผลิตภัณฑ์ IPA เป็นหลักฐานอ้างอิง

วันที่ 31–60: ทำ FAT/SAT กับหนึ่งผลิตภัณฑ์

เลือกกล้อง Gateway หรือ Sensor ที่ทดสอบ Update/Log ได้ รับ RFP Response พร้อมหลักฐาน ทดสอบ Identity, Version, Hardening, Communication, Update และ Log ใน FAT จากนั้นติดตั้งใน Zone จำกัดเพื่อ SAT เรื่องสิทธิ์ Fault, Recovery และการปฏิบัติการท้องถิ่น

วันที่ 61–90: ฝังบทเรียนในสัญญาและ Monitoring

นำ Gap กลับไปแก้ Standard Clause, Inspection Criteria, Support SLA และ Change Notification กำหนดเจ้าของ/รอบตรวจ IPA กับ Firmware จริง นำ Overdue Update, Exception, Support End และ Critical Vulnerability เข้าประชุมโรงงานและผู้บริหาร

เป้าหมายไม่ใช่รับรองทุกโรงงานใน 90 วัน แต่สร้างวงจรที่ทำซ้ำได้หนึ่งชุด ตั้งแต่ Requirement และ Evidence ถึง Acceptance และ Lifecycle Control แล้วค่อยขยายข้ามประเทศ

FAQ: JC-STAR สำหรับฐานต่างประเทศและโรงงานไทย

JC-STAR คืออะไร?

เป็นโครงการสมัครใจของญี่ปุ่นเพื่อประเมินและแสดงความสอดคล้องของฟังก์ชันความปลอดภัยในผลิตภัณฑ์ IoT ที่ใช้ IP หลากหลายชนิด ★1 เป็น Baseline ร่วม ระดับสูงขึ้นตอบประเภทและ Assurance ไม่ได้รับรองระบบติดตั้งทั้งหมด

JC-STAR บังคับใช้กับโรงงานไทยหรือไม่?

ไม่ใช่ข้อบังคับทางกฎหมายไทยแบบครอบคลุม แต่กลุ่มบริษัทญี่ปุ่นกำหนดเป็นเกณฑ์จัดซื้อภายในได้ กฎหมายไทย กฎอุตสาหกรรม เงื่อนไขลูกค้า และ Site Risk ต้องตรวจแยก

ฉลากรับรองระบบโรงงานทั้งหมดหรือไม่?

ไม่ ฉลากครอบคลุมผลิตภัณฑ์และขอบเขตที่ลงทะเบียน Network, Cloud, Account, Configuration, Service Access, Operator และ Update Process ต้องตรวจด้วย Design Review, FAT, SAT และ Operation

ควรกำหนด ★1 หรือ ★3 ใน RFP?

อย่าเลือกจากตัวเลขเพียงอย่างเดียว พิจารณาเกณฑ์ที่มีจริงตามประเภท ความสำคัญ ผลต่อ Production/Safety Exposure และความจำเป็นของ Third-party Evaluation ตรวจข้อมูล IPA ล่าสุดก่อนออก RFP

ค่าใช้จ่ายและอายุฉลากเท่าใด?

ณ 9 กันยายน 2026 IPA ระบุค่าธรรมเนียมสมัคร ★1 ปกติ 198,000 เยนรวมภาษี ไม่รวมค่าผู้ประเมินหรือผู้ตรวจพิสูจน์ ฉลากใหม่มีอายุสูงสุดสองปี เงื่อนไขของระดับ การต่ออายุ และ Mutual Recognition ต่างกัน จึงต้องตรวจ IPA ก่อนยื่นจริง

Mutual Recognition ทำให้ไม่ต้องตรวจเพิ่มหรือไม่?

ไม่ ข้อตกลง UK PSTI และ Singapore CLS ครอบคลุมเกณฑ์และขั้นตอนที่กำหนด อาจต้องยื่นเพิ่มและให้ข้อมูลเพิ่ม ไม่ทำให้ผ่านข้อกำหนดไทยอัตโนมัติ ต้องตรวจทิศทาง ขอบเขต อาณาเขต ข้อยกเว้นและค่าใช้จ่ายรายกรณี

หลักฐานขั้นต่ำสำหรับเกณฑ์จัดซื้อคืออะไร?

URL IPA, หมายเลขทะเบียน รุ่น/เวอร์ชันตรง สถานะปัจจุบัน ช่องทางช่องโหว่ Update Period, Communication Matrix, Secure Initialization, Log ตัวอย่าง, EOL/EOS Policy และผล FAT/SAT โลโก้หรือคำว่า “วางแผนรองรับ” ไม่พอ

สรุป: เชื่อมเส้นฐานญี่ปุ่นกับหลักฐานจริงในไทย

คุณค่าของ JC-STAR สำหรับฐานต่างประเทศไม่ใช่เพียงซื้อสินค้ามีดาว แต่คือการให้สำนักงานใหญ่มีภาษากลางด้าน Product Security ขณะที่โรงงานไทยพิสูจน์การติดตั้งจริงและติดตามฉลาก Firmware ช่องโหว่ และอายุ Support อย่างต่อเนื่อง

ตรวจรุ่นและเวอร์ชัน เลือกระดับที่ใช้ได้ กำหนดหลักฐานใน RFP ล็อกของส่งมอบใน FAT ทดสอบบทบาทของผู้ปฏิบัติงานและเส้นทางเครือข่ายจริงใน SAT และติดตาม Update/Exception หลังตรวจรับ อ่าน Mutual Recognition ตามขอบเขตที่ประกาศและแยกจาก Local Compliance

TOMAS TECH สนับสนุนโครงการ IoT/OT ในโรงงานไทยตั้งแต่สำรวจอุปกรณ์ จัดทำข้อกำหนด ออกแบบการสื่อสารและสิทธิ์ จัดเตรียมหลักฐาน FAT/SAT ไปจนถึงคู่มือการปฏิบัติงานในพื้นที่ สามารถ ติดต่อเรา ได้ตั้งแต่ช่วงเปรียบเทียบผลิตภัณฑ์หรือร่าง RFP

แหล่งข้อมูลปฐมภูมิ

• IPA: JC-STAR
• IPA: รายละเอียดโครงการ
• IPA: ขั้นตอนสมัครและรายงาน
• IPA: วิธีตรวจสอบฉลาก
• IPA: รายการผลิตภัณฑ์
• IPA: การนำไปใช้และ Mutual Recognition
• IPA: ขั้นตอน UK PSTI
• METI: การเริ่ม JC-STAR
• METI: คู่มือระบบเฉพาะภาค
• METI: บันทึกญี่ปุ่น–สิงคโปร์

*สถานะโครงการ ค่าธรรมเนียม ขั้นตอนการยอมรับร่วม และข้อมูลผลิตภัณฑ์อาจเปลี่ยน บทความนี้อ้างอิงข้อมูลสาธารณะที่ตรวจเมื่อ 9 กันยายน 2026 โปรดตรวจ IPA, METI และหน่วยงานประเทศที่เกี่ยวข้องอีกครั้งก่อนจัดซื้อ ยื่นสมัคร หรือตัดสินข้อกฎหมาย*