วิธีตรวจสอบผู้ผลิตที่ได้รับ JC-STAR สำหรับการจัดซื้ออุปกรณ์ IoT ในโรงงานไทย

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

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

รายชื่อผู้ผลิตที่ได้รับ JC-STAR ยังไม่ใช่คำตอบสำหรับการจัดซื้อ

รายการทางการของ IPA เป็นจุดเริ่มต้นที่ดี เมื่อนับข้อมูลจากไฟล์ Excel ทางการซึ่งอัปเดตล่าสุดวันที่ 4 กันยายน 2026 พบ 338 รายการ และ ณ เวลานั้นทั้ง 338 รายการแสดงสถานะมีผล โดยมีผู้ถือฉลากไม่ซ้ำ 138 ราย การเขียน “★1” แบบตัวเลขครึ่งความกว้างและเต็มความกว้างถูกปรับให้เป็นระดับเดียวกัน จำนวนตามหมวด ณ เวลานั้นประกอบด้วยกลุ่มพลังงาน 139 รายการ อุปกรณ์สื่อสาร 86 รายการ อุปกรณ์ป้องกันความปลอดภัย 42 รายการ คอนโทรลเลอร์ เช่น PLC/DCS 9 รายการ IoT Gateway 4 รายการ ผลิตภัณฑ์ด้านการผลิตและการกระจายสินค้า 2 รายการ และหุ่นยนต์อัตโนมัติ 2 รายการ เป็นต้น ตั้งแต่ 1 สิงหาคม 2026 เป็นต้นมา มี 21 รายการจากผู้ถือฉลาก 18 ราย

ตัวเลขเหล่านี้เป็น Snapshot จากไฟล์ Excel ณ วันที่ 4 กันยายน 2026 เท่านั้น จำนวนและสถานะอาจเปลี่ยนได้ จึงต้องดาวน์โหลดรายการใหม่ในวันที่อนุมัติสั่งซื้อ วันที่รับมอบ และระหว่างการทบทวนการใช้งาน บันทึกว่า “เคยมีผลในเดือนกันยายน 2026” ไม่เพียงพอสำหรับการตรวจสอบในอนาคต

ผู้ถือฉลาก 138 รายไม่ได้หมายความว่าสินค้าทุกชิ้นของ 138 บริษัทได้รับการรับรอง บริษัทเดียวอาจมีทั้งซีรีส์ที่ขึ้นทะเบียนและยังไม่ขึ้นทะเบียน แม้เป็นชื่อซีรีส์เดียวกันก็อาจครอบคลุมเฉพาะรุ่นหรือ Hardware Revision บางแบบ ดังนั้น Key ในการตัดสินใจคือ Registration Number + Product/Model Range + Level + Status + Validity ไม่ใช่ชื่อผู้ผลิตเพียงอย่างเดียว

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

หลักสำคัญ: ฉลาก JC-STAR ไม่ใช่การรับประกันความปลอดภัยอย่างสมบูรณ์

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

วิธีประเมินยังต่างกันตามระดับ ★1 และ ★2 เป็นการประกาศการสอดคล้องด้วยตนเองโดยใช้ Checklist การประเมินของ Vendor ส่วน ★3 และ ★4 เป็นการประเมินโดยบุคคลที่สามอิสระ จึงไม่ควรใช้จำนวนดาวเป็นการจัดอันดับสินค้าแบบง่ายๆ แต่ควรกำหนดใน RFP ว่ากรณีใช้งานต้องการระดับความเชื่อมั่นเท่าใด ใครประเมินอะไร และ Configuration ใดอยู่ในขอบเขต

Sensor ที่ไม่มีเส้นทางออก Internet โดยตรงย่อมมีเงื่อนไขต่างจาก Gateway ที่เป็นจุดผ่านของ Remote Maintenance ตรงขอบเขต Production Network กล้อง ระบบจัดการพลังงาน และอุปกรณ์ใกล้ PLC ก็มี Attack Path และผลกระทบจาก Downtime ต่างกัน JC-STAR เป็นหนึ่งในแกนเปรียบเทียบ แต่ไม่แทนที่ Risk Assessment ของโรงงาน

ตรวจสอบผลิตภัณฑ์ JC-STAR ด้วย 7 รายการ

ควรใช้ Evidence Sheet เดียวที่ประกอบด้วย 7 รายการต่อไปนี้ ฝ่ายจัดซื้อไม่ควรกรอกและอนุมัติฝ่ายเดียว แต่ให้ OT, IT, QA, ซ่อมบำรุง และกฎหมายเมื่อจำเป็น ใช้ Record เดียวกัน

1. Registration Number

หมายเลขทะเบียนเป็น Primary Key สำหรับเชื่อมหลักฐาน ต้องใช้หมายเลขเดียวกันในคำตอบ RFP การตรวจใบเสนอราคา การอนุมัติ PO รายงาน FAT รายงาน SAT และทะเบียนทรัพย์สิน ชื่อผู้ผลิตหรือชื่อทางการค้าเพียงอย่างเดียวไม่เพียงพอเมื่อข้อมูลทะเบียนเปลี่ยน

กำหนดให้ Supplier ส่ง URL ทางการและหมายเลขทะเบียน หากเก็บ Screenshot เป็นหลักฐาน ให้ใส่วันที่ ผู้ตรวจ และ URL และควรเก็บข้อมูลรายการของวันนั้นไว้ด้วย ห้ามอนุมัติจากภาพโลโก้ใน Sales Deck เพียงอย่างเดียว

2. ช่วงรุ่นที่ครอบคลุม

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

แม้ Base Unit อยู่ในขอบเขต แต่โมดูลสื่อสารภายนอกหรือ Option Card อาจไม่อยู่ใน Configuration ที่ประเมิน ต้องขอ Configuration Table ที่รวมตัวเครื่อง Option บังคับ อุปกรณ์เสริม Management Software และ Cloud Service หากชื่อในใบเสนอราคาและเอกสารประเมินต่างกัน ให้ขอ Mapping อย่างเป็นทางการจากผู้ผลิต ไม่รับคำว่า “รุ่นเทียบเท่า” โดยไม่มีหลักฐาน

3. Status

ยืนยันว่าสถานะมีผล ณ วันที่อนุมัติสั่งซื้อ เนื่องจากรายการทางการอาจมีสถานะอื่น ประวัติว่าเคยได้รับเพียงอย่างเดียวจึงไม่พอ บันทึกการตรวจวันที่ปิด RFP วันที่อนุมัติ PO และวันที่รับมอบ เพื่อให้โครงการที่ Lead Time ยาวตรวจพบการเปลี่ยนแปลงได้

คำว่า “อยู่ระหว่างยื่น” หรือ “มีแผนรองรับ JC-STAR” ไม่เท่ากับขึ้นทะเบียนแล้ว IPA เตือนเรื่องข้อความที่อาจทำให้เข้าใจผิด เช่น “JC-STAR適合予定” การรับสมัคร ★1 เริ่มวันที่ 25 มีนาคม 2025 และ ณ วันที่ 31 กรกฎาคม 2026 IPA แจ้งว่าจำนวนคำขอเพิ่มสูง ทำให้การตรวจใช้เวลานานกว่าปกติ หากสัญญาอนุญาตให้ได้ทะเบียนก่อนส่งมอบ ต้องกำหนดรุ่นทดแทน กำหนดเวลา การประเมินใหม่ และผลทางสัญญาหากไม่ได้ทะเบียนไว้ล่วงหน้า

4. Validity Period

วางวันสิ้นสุดความมีผลเทียบกับวันเริ่มและสิ้นสุดการใช้งานที่คาดไว้ หากหมดอายุไม่นานหลังส่งมอบ ให้ถามแผนต่ออายุ หลักฐานระหว่างต่ออายุ และวิธีจัดการหากไม่ต่ออายุ เครื่องจักรที่ใช้ยาวนานต้องมีแผนทบทวนตลอด Maintenance Period ไม่ใช่ตรวจครั้งเดียวตอนซื้อ

อย่าสับสนวันสิ้นสุดฉลากกับวันสิ้นอายุการใช้งานทางกายภาพ การหมดอายุไม่ได้แปลว่าอุปกรณ์ไม่ปลอดภัยทันทีในวันนั้น แต่เป็น Trigger ให้ประเมินว่าพื้นฐานการรับรองยังใช้ได้หรือไม่ ตัวอย่างเช่น ระบบทะเบียนอาจเปิดงานทบทวน 90 วันก่อนหมดอายุ หากองค์กรตกลง Lead Time นี้ไว้แล้ว ตัวอย่าง 90 วันนี้เป็นกฎภายใน ไม่ใช่ข้อกำหนด JC-STAR ที่ใช้กับทุกองค์กร

5. Published Assessment Result

อ่านผลการประเมินหรือข้อมูลการสอดคล้องที่เปิดเผยเพื่อดูเกณฑ์ ระดับ และ Configuration ที่อยู่ในขอบเขต บันทึกว่าเป็น Self-declaration สำหรับ ★1/★2 หรือ Third-party Evaluation สำหรับ ★3/★4 การบันทึกเพียงว่า “มีดาว” ทำให้ Audit ไม่เห็นว่าใครเป็นผู้ประเมิน

นำหลักฐานที่มีไปจับคู่กับ Control ที่โรงงานต้องการ เช่น Credential, Initial Password, Software Update, Communication Protection, Log และช่องทางรับแจ้งช่องโหว่ หากเอกสารสาธารณะไม่ยืนยันข้อใด ให้ขอหลักฐานจาก Supplier หรือใส่ Test Case ใน FAT รายการที่ยังไม่ทราบต้องคงสถานะ Open พร้อม Owner และ Due Date ไม่ควรเปลี่ยนเป็น “Compliant” โดยอัตโนมัติ

6. Firmware Condition

ยืนยันเวอร์ชันเฟิร์มแวร์ในหลักฐาน เวอร์ชันที่ส่งมอบ เวอร์ชันล่าสุดที่แนะนำ วิธีอัปเดต การตรวจลายเซ็น และวิธี Rollback หากอุปกรณ์ขึ้นทะเบียนแต่ใช้เฟิร์มแวร์ต่างจากที่ประเมิน อาจต้องวิเคราะห์เพิ่มเติม

ในโรงงานไทย Machine Builder อาจขอใช้เวอร์ชันเก่าเพื่อความเสถียร ขณะที่ IT ขอเวอร์ชันใหม่เพื่อแก้ช่องโหว่ ไม่ควรใช้หลักของฝ่ายใดโดยไม่ประเมิน ต้องทำ Change Control ที่พิจารณาความเข้ากันได้ ช่องโหว่ Downtime หลักฐานทดสอบ และ Recovery บันทึกเวอร์ชันออกโรงใน FAT เวอร์ชันติดตั้งจริงใน SAT และเวอร์ชันปัจจุบันในทะเบียน แล้วสอบสวนเมื่อไม่ตรงกัน

7. Support Period

ระยะมีผลของฉลากและระยะสนับสนุนจาก Vendor เป็นคนละข้อมูล บันทึก End of Security Updates, End of Sale, End of Maintenance และวันสิ้นสุด Cloud Service ที่เกี่ยวข้อง หากวันยังไม่แน่นอน ให้ระบุช่องทางแจ้งเตือน ระยะเวลาแจ้งล่วงหน้า นโยบายต่อช่องโหว่รุนแรง และการย้ายไปรุ่นทดแทนในเงื่อนไขสัญญา

อุปกรณ์โรงงานมักใช้นาน ความสามารถในการอัปเดตและเปลี่ยนทดแทนอาจสำคัญกว่าราคาต่อหน่วย หากใช้ Spare Part ยืดอายุ อย่าปล่อยอุปกรณ์ที่ไม่มี Support อย่างไม่มีกำหนด ต้องบันทึก Compensating Control เช่น Network Segmentation, Restricted Access, Monitoring และวันเลิกใช้ที่อนุมัติแล้ว

เปลี่ยนมาตรฐานจัดซื้อ IoT จากระดับผู้ผลิตเป็นระดับผลิตภัณฑ์

ข้อกำหนดว่า “ผู้ผลิตต้องได้รับ JC-STAR” อาจถูกตีความว่าบริษัทมีทะเบียนเพียงผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งก็ผ่าน รูปแบบที่ชัดกว่าคือ “Sales Model ที่เสนอ รวม Configuration และเฟิร์มแวร์ส่งมอบ ต้องอยู่ในขอบเขตทะเบียนที่เกี่ยวข้อง ณ วันที่ตรวจสอบที่กำหนด”

แต่ละ Use Case ควรกำหนดว่า JC-STAR เป็น Mandatory, Scoring หรืออนุญาต Equivalent Evidence หากบังคับทุกกรณีในตลาดที่ผู้ขายน้อย อาจกระทบ Maintainability หรือ Business Continuity ในทางกลับกัน Gateway ตรง Boundary อุปกรณ์ Remote Managed หรืออุปกรณ์ที่ติดตั้งจำนวนมากย่อมได้ประโยชน์จาก Assurance Requirement ที่ชัด ต้องเชื่อม Requirement กับ Risk และ Connectivity ของผลิตภัณฑ์

หน้า Registered Products ของ IPA เพิ่ม CLS Mutual Recognition List วันที่ 1 มิถุนายน 2026 และ PSTI Declaration of Conformity List วันที่ 14 มกราคม 2026 CSA สิงคโปร์ระบุว่า MoC ญี่ปุ่น–สิงคโปร์ลงนามวันที่ 18 มีนาคม 2026 และ Mutual Recognition มีผลวันที่ 1 มิถุนายน 2026 ตัวอย่างผลิตภัณฑ์คือ Smart Home, Alarm และ IoT Gateway/Hub โดยมีเป้าหมายช่วยลดขั้นตอนการขอฉลากอีกประเทศของผู้ผลิต

อย่างไรก็ตาม ห้ามขยายความว่าใช้กับทุกผลิตภัณฑ์ ทุกระดับ หรือยอมรับอัตโนมัติในไทย หากผลิตภัณฑ์อยู่ใน Mutual Recognition List ก็ยังต้องตรวจรายการ Scope Model และ Condition เป็นรายกรณี

เขียน JC-STAR Procurement Requirement ลงใน RFP

หลีกเลี่ยงคำถาม Yes/No ว่า “ได้รับการรับรองหรือไม่” ให้กำหนดรูปแบบหลักฐาน วันที่ฐาน และความรับผิดชอบเมื่อมีการเปลี่ยนแปลง ตารางเปรียบเทียบควรมีรายการต่อไปนี้

ระบุวันที่ฐาน เช่น รายการทางการ ณ วันเสนอราคา และสงวนสิทธิ์ตรวจซ้ำก่อนสั่งซื้อ ในสัญญาควรบังคับให้แจ้งเมื่อ Status หรือ Model Scope เปลี่ยนก่อนส่งมอบ ห้ามเปลี่ยนเป็น “รุ่นเทียบเท่า” โดยไม่ได้อนุมัติ และให้นำรุ่นทดแทนเข้ากระบวนการประเมินใหม่

กรณี Network Infrastructure ดูรายการ Management Plane, Remote Service, Log และ Segmentation เพิ่มเติมจาก แนวทาง RFP อุปกรณ์เครือข่ายด้วย JC-STAR ส่วนโครงการกล้องให้ใช้ แนวทางจัดซื้อ Network Camera ที่รองรับ JC-STAR เพื่อครอบคลุม Video Data, Account, Recorder และ Cloud Link

FAT: ทำให้ Shipping Configuration ตรวจสอบย้อนหลังได้

FAT ต้องยืนยันว่าเอกสารการสอดคล้องตรงกับเครื่องจริง ใส่หมายเลขทะเบียนใน Test Record และเก็บหลักฐาน Label, Nameplate, Sales Model, Hardware Revision, Serial Number และ Firmware

ตรวจ Model, Option และ Firmware

เทียบ Quotation BOM, Manufacturing BOM, Shipping BOM และอุปกรณ์จริง สำหรับโมดูลสื่อสารเสริม Management Server, Mobile App หรือ Cloud Service ต้องระบุว่าส่วนใดอยู่ใน Scope ของทะเบียนและส่วนใดต้องประเมินเพิ่มโดยโรงงาน

ทดสอบการเริ่มใช้งานและ Authentication

ทดสอบ Initial Credential, การบังคับเปลี่ยนเมื่อ Login ครั้งแรก, Account ที่ไม่จำเป็น, Privilege Separation, Password Recovery และ Certificate Enrollment จากนั้นตรวจว่า Factory Default ที่ปลอดภัยไม่ได้ถูกทำให้อ่อนลงตอน Integrate หน้างานด้วย Shared Password จึงต้องตรวจ Work Instruction และ Completion Evidence

ทดสอบ Update, Recovery และ Log

ทดสอบการตรวจ Firmware ที่ถูกต้อง Recovery เมื่อ Update ล้มเหลว ข้อจำกัด Rollback, Configuration Backup และการดึง Event Log หากอัปเดตจริงไม่ได้ การแก้ช่องโหว่จะช้าแม้ประกาศ Support Period ยาว ใช้ Test Environment ประเมิน Downtime และเชื่อมผลกับ Production Change Approval

ปิด Nonconformity ก่อนส่งมอบ

อย่าปิดปัญหา FAT ด้วย Pass/Fail อย่างเดียว ให้บันทึก Corrective Action, Due Date, Retest และ Exception Approver รุ่นอยู่นอก Scope, Firmware Baseline ไม่ชัด หรือไม่มี Update Procedure จะแก้แพงกว่าหลังติดตั้ง ต้องมี Shipment Release Gate ที่หยุดส่งได้จนหลักฐานครบ

SAT: ประเมินซ้ำภายใต้การเชื่อมต่อจริงของโรงงานไทย

เมื่อเชื่อมต่อ Plant Network ความเสี่ยงจะต่างจากใน FAT ดังนั้น SAT ต้องตรวจ Location, Zone, Access Path, Time Sync, Monitoring, Backup และ Asset Registration ไม่ใช่ตรวจ Function อย่างเดียว

ยืนยันว่าอุปกรณ์ต่อ VLAN หรือ Security Zone ตามแบบ และไม่มี Internet Traffic หรือ Management Port ที่ไม่คาดหมาย หากใช้ Remote Support ให้ทดสอบ Request, Approval, Time Limit, Logging และ Explicit Closure แทนการเปิดทางไว้ตลอดเวลา

ตรวจ Time Synchronization, Log Forwarding, Alert Monitoring, Backup และ Recovery ให้ครบถ้วน Log ที่เวลาไม่ตรงกันใช้สืบสวน Incident ได้ยาก และความสามารถสร้าง Log ไม่เพียงพอหากไม่มี Destination, Retention และผู้รับผิดชอบอ่าน

สุดท้ายเชื่อม Asset ID จริงกับ Registration Number ใน Operational Register หากมีการเปลี่ยน Firmware หรือ Configuration ระหว่าง Commissioning ให้บันทึกผลต่อ Evaluated Baseline และสอบถาม Supplier เมื่อจำเป็น วันที่ SAT ผ่านคือจุดเริ่มของ Operational Assurance ไม่ใช่จุดสิ้นสุดของงาน Security

ใช้ 3 Gate: สั่งซื้อ รับมอบ และใช้งาน

การตรวจผลิตภัณฑ์ที่รองรับ JC-STAR ไม่ใช่ Checklist ที่ทำครั้งเดียว แต่เป็นการควบคุมตลอด Lifecycle เพื่อจับทั้งการเปลี่ยนแปลงสถานะและการเปลี่ยนแปลง Configuration

Purchase Gate

ตรวจ Registration Number, Model Scope, Level, Status และ Validity เทียบหลักฐาน Supplier กับรายการทางการ ทำ Risk Assessment ตาม Use Case และกำหนด Compensating Control กับ Approver สำหรับข้อที่ไม่ครบ บันทึกวันที่ดึงข้อมูลใน Purchase Approval

Delivery Gate

ใช้ FAT และ Receiving Inspection ยืนยันว่า Model, Hardware, Firmware และ Option ที่ส่งมาตรงกับ Approved Configuration ดึงรายการทางการใหม่เพื่อตรวจการเปลี่ยน Status หลังสั่งซื้อ หากไม่ตรงให้ Quarantine ก่อนติดตั้งและทำ Difference Assessment

Operational Gate

ติดตาม Validity, Support End, Vulnerability Notice, Firmware Update และ Configuration Change ใช้ทั้ง Periodic Review และ Event Trigger เช่น Critical Vulnerability, Supplier Notice, Network Change หรือ Change of Use คำถามคือเครื่องจริงยังตรงกับ Baseline ที่ตรวจแล้วหรือไม่ ไม่ใช่เคยมีฉลากหรือไม่

จัดทำทะเบียนที่เชื่อมหลักฐานตลอดวงจรชีวิต

อย่างน้อยควรมี 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/Next Review, Exception, Compensating Control และ Retirement Plan

ข้อมูลไม่จำเป็นต้องอยู่ใน Procurement System, CMDB, Equipment Register หรือ Maintenance Platform ตัวเดียว แต่ต้องอ้างอิงข้ามกันด้วย Registration Number และ Internal Asset ID และต้องกำหนดเจ้าของข้อมูล ฝ่ายจัดซื้อดู Contract และ Supplier Notice, OT ดู Configuration กับ Downtime, IT ดู Network และ Vulnerability, Maintenance ดูตัวเครื่องและการเปลี่ยน, QA ดู Acceptance Evidence

เริ่มด้วย Excel ได้หากควบคุม Field Definition, Editor, Due Date, History และ Approval Rule ในทางกลับกัน ระบบ Asset ราคาแพงก็ไม่สร้างหลักฐานที่ดี หาก Model Scope และ Firmware ว่างอยู่

ตำแหน่งของ JC-STAR ในประเทศไทย

ผู้ที่ค้นหา “JC-STAR ไทย” ไม่ควรสรุปว่าเป็นข้อกฎหมายบังคับสำหรับทุกโรงงาน แนวทางนี้ใช้ข้อมูล JC-STAR ภายใน Governance ของกลุ่มบริษัทญี่ปุ่นหรือ Requirement ของลูกค้าที่โรงงานไทย ส่วนกฎหมายไทย กฎอุตสาหกรรม วิทยุ การนำเข้า และสัญญา ต้องตรวจตามผลิตภัณฑ์และ Use Case แยกต่างหาก

วันที่ 12 มีนาคม 2026 NCSA ไทยเปิดรับความเห็นต่อร่างแนวทาง Cybersecurity สำหรับ IoT ของผู้ใช้ทั่วไป โดยระบุความสอดคล้องกับ ISO/IEC 27400/27402 และ ETSI EN 303 645 ข้อมูลนี้สะท้อนทิศทางนโยบาย แต่ร่างรับฟังความคิดเห็นไม่ควรถูกนำเสนอเป็นกฎหมายสุดท้ายหรือ Requirement บังคับของทุกโรงงาน

dSURE ของ depa เป็นกรอบรับรองผลิตภัณฑ์ IoT และ Digital ของนิติบุคคลไทย โดยมีเกณฑ์ Security, Safety และ Functionality ไม่ควรกล่าวว่าเหมือนกับ JC-STAR หรือมี Mutual Recognition แล้ว หากเกี่ยวข้องทั้งสองกรอบ ให้เปรียบเทียบ Eligible Organization, Product Scope, Criteria, Applicant และผลทางกฎหมายหรือพาณิชย์แยกกัน

คู่มือ METI วาง JC-STAR เป็นข้อมูลอ้างอิงสำหรับการจัดซื้อ IoT ที่รวมในระบบเฉพาะสาขา ผู้ซื้อจึงต้องแปลงข้อมูล Scheme ให้เป็น Control ที่ใช้ได้จริง การเขียนชื่อฉลากใน RFP ไม่พอ ต้องเชื่อมกับ Risk, Evidence, Acceptance Test และ Monitoring

การแบ่งหน้าที่ตามหน่วยงาน

ฝ่ายจัดซื้อดูแล Registration Number, Sales Model, ราคา, Lead Time, สัญญา และ Change Notice จาก Supplier ฝ่าย OT กำหนด Use Case, ผลกระทบจาก Downtime, Network Configuration, การเดินระบบทดแทน และช่วงเวลาที่อัปเดตได้ ฝ่าย IT และ Security ตรวจ Authentication, Communication, Log, การตอบสนองช่องโหว่ และ Remote Access ส่วน QA ตรวจว่าหลักฐานต่อเนื่องตั้งแต่คำตอบ RFP ผ่าน FAT, SAT จนถึง Acceptance Record หรือไม่

ผู้ผลิตเครื่องจักรหรือ SIer ต้องรับผิดชอบในฐานะผู้ให้ข้อมูล Configuration ไม่ใช่เพียงผู้ส่งมอบสินค้า สัญญาควรกำหนดให้แจ้งล่วงหน้าและขออนุมัติใหม่เมื่อมีการเปลี่ยนชิ้นส่วน สินค้าทดแทน Firmware หรือข้อกำหนด Cloud Service ฝั่งโรงงานเองก็ต้องบันทึกการอัปเดตผ่าน USB หรือการเปลี่ยนค่า Configuration ที่ทำตามการตัดสินใจหน้างาน

ที่ประชุมควรติดตามจำนวนรายการที่ยังไม่ยืนยัน กำหนดเวลา เจ้าของงาน และผลกระทบจาก Downtime มากกว่าจำนวนดาวหรือชื่อเสียงของผู้ผลิต การใช้สถานะ เช่น ตรวจหลักฐานครบ อนุมัติแบบมีเงื่อนไข อยู่ระหว่างแก้ไข หมดอายุ และอนุมัติข้อยกเว้น ช่วยให้ฝ่ายจัดซื้อและฝ่ายปฏิบัติการบริหารข้อเท็จจริงชุดเดียวกันได้

ความผิดพลาดที่พบบ่อย

ใช้รายชื่อผู้ผลิตเป็น Approved Vendor List

List ระดับบริษัทอาจทำให้อนุมัติผลิตภัณฑ์ที่ไม่ขึ้นทะเบียน ต้องบริหาร Registration Number คู่กับ Sales Model และตรวจใหม่ทุก Proposal

รับโลโก้ใน Sales Material เป็นหลักฐาน

โลโก้หรือคำว่า “มีแผนรองรับ” ไม่ยืนยัน Scope และ Status ปัจจุบัน ต้องตรวจรายการทางการและเก็บ Number, Validity, Retrieval Date

ตรวจเฉพาะตอนออก PO

Model, Firmware และ Status เปลี่ยนก่อนส่งมอบได้ ต้องใช้ Purchase, Delivery และ Operational Gate

คิดว่า Validity กับ Support เป็นวันเดียวกัน

Registration Validity, End of Sale, End of Maintenance, End of Security Update และ Cloud End เป็นคนละวัน ต้องแยก Field และใช้ข้อจำกัดที่มาถึงก่อนใน Upgrade Plan

ใช้ ★1 และ ★3 เป็นหลักฐานชนิดเดียวกัน

★1/★2 เป็น Self-declaration ส่วน ★3/★4 เป็น Independent Evaluation ต้องจับคู่ระดับ Assurance กับ Use Case และชดเชย Gap ด้วย Evidence หรือ Test

เดาความสัมพันธ์กับกรอบของไทย

JC-STAR, ร่าง NCSA และ dSURE มีวัตถุประสงค์และสถานะต่างกัน ห้ามกล่าวว่าเหมือนกัน Mutual Recognition หรือเป็นข้อกฎหมายโดยไม่มี Primary Evidence สำหรับกรณีนั้น

FAQ: ผู้ผลิต JC-STAR และการจัดซื้อ IoT

ผู้ผลิตที่ได้รับ JC-STAR หมายถึงสินค้าทุกชิ้นได้รับหรือไม่

ไม่ใช่ ขอบเขตอยู่ที่ผลิตภัณฑ์ ช่วงรุ่น และ Configuration ในรายการทางการ ต้องตรวจว่า Sales Model และ Hardware Revision ที่เสนออยู่ในขอบเขต

ผลิตภัณฑ์ JC-STAR ปลอดภัยสมบูรณ์หรือไม่

ไม่ใช่ IPA ระบุว่าฉลากไม่รับประกันความปลอดภัยสมบูรณ์ ต้องใช้ Level และ Assessment Method ร่วมกับ Risk Assessment ตามการใช้งาน Network Exposure และ Downtime Impact

JC-STAR Procurement Requirement ต้องมีอะไร

ควรมี Registration Number, Official URL, Sales Model, Hardware Revision, Level, Assessment Method, Status, Validity, Firmware, Update Process, Support Period, Vulnerability Contact, Change Notice และ Exception Handling พร้อม Baseline Date และการตรวจซ้ำตอนรับมอบ

ซื้อผลิตภัณฑ์ที่เขียนว่า “มีแผนรองรับ JC-STAR” ได้หรือไม่

เป็นการตัดสินใจของโครงการ แต่ห้ามถือว่าได้ทะเบียนแล้ว หากยอมให้ได้ก่อน Delivery ต้องกำหนด Alternative, Schedule, Reassessment และ Contract Treatment เมื่อไม่สำเร็จ

JC-STAR เป็นข้อกฎหมายบังคับในโรงงานไทยหรือไม่

บทความนี้ไม่ถือว่าเป็นข้อบังคับสากลสำหรับทุกโรงงานหรืออุปกรณ์ในไทย สามารถใช้เป็น Group/Customer Procurement Governance พร้อมตรวจ Thai Legal, Sector, Radio, Import และ Contract Requirement แยกกัน

depa dSURE กับ JC-STAR มี Mutual Recognition หรือไม่

ไม่ควรสรุปเช่นนั้น dSURE มีเกณฑ์ Security, Safety และ Functionality สำหรับองค์กรไทยที่เข้าเงื่อนไข ต้องตรวจ Product Scope, Applicant, Criteria และ Effect ของแต่ละกรอบจากข้อมูลปฐมภูมิ

หมด Validity แล้วต้องหยุดอุปกรณ์ทันทีหรือไม่

ไม่ควรตัดสินจากวันที่เพียงอย่างเดียว ต้องดู Status, Vulnerability, Update, Exposure, Downtime Impact และ Compensating Control แต่การใช้ต่อควรมี Risk Owner, วันสิ้นสุดข้อยกเว้น และแผนแก้ไขหรือเปลี่ยน

สรุป: เชื่อม Registration Number ไปจนถึงอุปกรณ์ที่ใช้งานจริง

การค้นหาผู้ผลิตที่ได้รับ JC-STAR เป็นเพียงจุดเริ่มของการจัดซื้อ IoT ต้องตรวจ Registration Number, Model Scope, Status, Validity, Published Assessment, Firmware Condition และ Support Period ในระดับผลิตภัณฑ์ แล้วใช้ Identifier เดียวกันตลอด RFP, FAT, SAT และ Asset Register Snapshot ทางการวันที่ 4 กันยายน 2026 มี 338 รายการและผู้ถือฉลากไม่ซ้ำ 138 ราย แต่ตัวเลขและสถานะไม่ถาวร การตรวจซ้ำตอนสั่งซื้อ รับมอบ และใช้งาน ทำให้ฉลากกลายเป็น Control ที่ใช้ได้จริง

หากโรงงานของคุณอยู่ระหว่างออกแบบ Candidate Sheet, RFP Matrix, FAT/SAT Record หรือทะเบียน Asset/Firmware สามารถ ปรึกษา TOMAS TECH ได้ตั้งแต่ขั้นวางเกณฑ์ เราช่วยจัดโครงสร้างหลักฐานให้เข้ากับหน้าที่ของฝ่ายจัดซื้อ OT, IT, QA และซ่อมบำรุง โดยไม่เริ่มจากการล็อกผู้ผลิตรายใดรายหนึ่ง

แหล่งอ้างอิง

• IPA: ระบบ JC-STAR
• IPA: รายการผลิตภัณฑ์ JC-STAR
• IPA: ผลิตภัณฑ์ขึ้นทะเบียนและรายการ Mutual Recognition
• IPA: ข้อมูลสมัคร ★1 และ ★2
• METI: คู่มือใช้ข้อมูลการสอดคล้องด้านความปลอดภัย IoT
• Singapore CSA: Mutual Recognition กับญี่ปุ่น
• Thailand NCSA: ร่างแนวทาง Cybersecurity สำหรับ IoT
• depa: dSURE