เมื่อจัดหาอุปกรณ์เครือข่าย JC-STAR สำหรับโรงงานในประเทศไทย การเลือกระหว่าง Router, Managed Switch หรือ IoT Gateway จากการมีฉลากเพียงอย่างเดียวยังไม่เพียงพอ หลักฐานการจัดซื้อต้องเชื่อมโยงรุ่นและ Firmware (FW) ที่ถูกต้อง อายุของฉลาก ข้อมูลความสอดคล้องในญี่ปุ่น ข้อกำหนด NBTC หรือข้อกำหนดไทยที่เกี่ยวข้อง หลักฐาน FAT/SAT และผู้รับผิดชอบการอัปเดตหลังส่งมอบเข้าด้วยกัน
บทความนี้ไม่ใช่คำอธิบายระบบแบบกว้าง ๆ หรือรายชื่อผู้ผลิตที่ได้รับฉลาก แต่เป็นคู่มือเชิงปฏิบัติสำหรับโรงงาน SIer ฝ่ายจัดซื้อ และผู้รับผิดชอบ IT/OT Security ที่กำลังเปรียบเทียบและสั่งซื้ออุปกรณ์เพื่อนำเข้าประเทศไทยหรือซื้อในประเทศ โดยอธิบายว่าควรขอหลักฐานใดใน RFP ต้องตรวจซ้ำอะไรในช่วงรับมอบ และจะใช้ข้อกำหนดทดแทนอย่างไรเมื่อไม่พบรุ่นที่เสนอในทะเบียน
ข้อสรุป: ซื้อ “รุ่น × FW × อายุหลักฐาน × ความสอดคล้องไทย × เจ้าของงาน”
ฉลาก JC-STAR เป็นหลักฐานที่มีประโยชน์ แต่ไม่ใช่การรับประกันครอบคลุมทั้งแบรนด์หรือทุกรุ่นใน Series หน่วยที่ฝ่ายจัดซื้อควรล็อกอย่างน้อยประกอบด้วย:
- ผู้ผลิต ชื่อผลิตภัณฑ์ รุ่น SKU และ Hardware Revision ที่แน่นอน
- หมายเลขทะเบียน JC-STAR ระดับ และหน้าสาธารณะที่เปิดจาก QR
- เงื่อนไข FW ที่อยู่ในทะเบียน และ FW ที่ติดตั้งในเครื่องส่งมอบจริง
- ระยะเวลามีผล และวิธีตรวจสอบการหมดอายุ การยกเลิก หรือการเปลี่ยนแปลง
- ความสอดคล้องของอุปกรณ์วิทยุ/โทรคมนาคมในไทย เช่น NBTC ตามที่ใช้ ผู้รับผิดชอบนำเข้า เครื่องหมาย และเอกสารที่ต้องเก็บ
- ผู้รับผิดชอบตรวจซ้ำใน FAT ก่อนส่งออก ตอนนำเข้า ใน SAT และตอนส่งมอบให้ฝ่ายปฏิบัติการ
- เงื่อนไขการรับมือช่องโหว่ การอัปเดต FW การสำรอง Configuration การเปลี่ยนเครื่อง และการเลิกใช้งาน
JC-STAR ทำให้เห็นความสอดคล้องด้าน Cybersecurity ของผลิตภัณฑ์ IoT ภายใต้ระบบของญี่ปุ่น แต่ไม่แทนความสอดคล้องด้านวิทยุและโทรคมนาคมในประเทศไทย ในทางกลับกัน การมีทะเบียน การรับรอง หรือ SDoC ของ NBTC ก็ไม่ได้ทำให้ผ่านเกณฑ์ Cybersecurity ของโรงงานโดยอัตโนมัติ จึงต้องแยกเป็น Decision Gate สองชุด และไม่อนุมัติรุ่นจนกว่าหลักฐานทั้งสองฝั่งจะครบ
Timeline ปี 2025–2026 ที่ฝ่ายจัดซื้อต้องทราบ
JC-STAR เป็นระบบที่ประเมินและแสดงให้เห็นฟังก์ชันความปลอดภัยของผลิตภัณฑ์ IoT ตามเกณฑ์ที่กำหนดในญี่ปุ่น โดยสอดคล้องกับแนวทางสากล เช่น ETSI EN 303 645 และ NISTIR 8425 IPA เริ่มรับคำขอระดับ ★1 เมื่อวันที่ 25 มีนาคม 2025 และตั้งแต่ 22 เมษายน 2026 วิธีขอหมายเลขคำขอเปลี่ยนเป็นการสมัครผ่านแบบฟอร์มเฉพาะ
วันที่ 31 กรกฎาคม 2026 IPA แจ้งว่าจำนวนคำขอเพิ่มขึ้นอย่างรวดเร็ว ทำให้งานตรวจสอบใช้เวลานานกว่าปกติ ดังนั้น หากผู้ขายตอบว่า “อยู่ระหว่างยื่น” ฝ่ายจัดซื้อไม่ควรนำวันที่คาดว่าจะได้ฉลากที่ไม่มีหลักฐานไปวางเป็น Critical Path IPA ยังระบุว่าคำขออาจไม่ได้รับหรืออาจไม่ผ่าน และเตือนการใช้ข้อความที่ทำให้เข้าใจว่าได้รับหรือจะได้รับฉลากก่อนมีหลักฐานที่เหมาะสม ต้องแยกหมายเลขรับเรื่อง หมายเลขทะเบียนชั่วคราว และฉลากที่ได้รับจริงออกจากกัน
ประวัติการอัปเดตปัจจุบันบนหน้า IPA ระบุว่า วันที่ 12 มิถุนายน 2026 มีการเผยแพร่ข้อกำหนดความสอดคล้องระดับ ★3 สำหรับอุปกรณ์สื่อสารและกล้องเครือข่าย พร้อมอัปเดตข้อกำหนดด้านความปลอดภัยที่เกี่ยวข้อง ส่วนวันที่ 5 มิถุนายนเป็นการเผยแพร่ข้อกำหนดที่เกี่ยวกับการอนุมัติหน่วยประเมิน เอกสาร RFP จึงต้องจับคู่วันที่กับชื่อเอกสารจริง ไม่คัดลอกเฉพาะหัวข้อจากแหล่งข้อมูลรอง
| วันที่ | ข้อเท็จจริงที่เผยแพร่ | ผลต่อการจัดซื้อ |
|---|---|---|
| 2025-03-25 | เริ่มรับคำขอ ★1 | ตรวจผลิตภัณฑ์ที่ได้รับฉลากจากทะเบียนสาธารณะ |
| 2026-04-22 | เปลี่ยนวิธีขอหมายเลขคำขอ | ตรวจประเภทหมายเลขและผู้ออกหลักฐานของสถานะ “ยื่นแล้ว” |
| 2026-06-05 | เผยแพร่ข้อกำหนดที่เกี่ยวกับการอนุมัติหน่วยประเมิน | เป็นบริบทของกลไก Third-party สำหรับ ★3/★4 |
| 2026-06-12 | เผยแพร่ข้อกำหนดความสอดคล้อง ★3 สำหรับอุปกรณ์สื่อสารและกล้องเครือข่าย และอัปเดตข้อกำหนด Security ★3 ที่เกี่ยวข้อง | ระบุ Revision ปัจจุบันใน RFP ที่ต้องการ Assurance สูง |
| 2026-07-31 | แจ้งความล่าช้าเนื่องจากคำขอเพิ่มเร็ว | ไม่ผูกโครงการกับวันที่ได้ฉลากที่ยังไม่ยืนยัน |
ระดับ ★1 และ ★2 ใช้วิธี Self-declaration จากผลประเมินและ Checklist ของผู้ขายตามเกณฑ์และขั้นตอนที่กำหนด ส่วน ★3 และ ★4 อาศัยรายงานจากหน่วยประเมินอิสระ การมีดาวมากกว่าไม่แปลว่าเหมาะกับทุกโรงงาน ต้องเลือกระดับตามตำแหน่งติดตั้ง Trust Boundary ความสำคัญต่อการผลิต Threat Model และ Compensating Controls
เหตุผลที่ต้องโฟกัส Router, Switch และ IoT Gateway
อุปกรณ์เครือข่ายอยู่ตรง Trust Boundary ระหว่างเครื่องจักรกับระบบระดับบน ระหว่างโรงงานกับ Cloud และระหว่างเครือข่ายผลิตกับช่องทาง Remote Maintenance Router หรือ Gateway ที่ตั้งค่าผิดหรือไม่ได้ Patch อาจกระทบพื้นที่กว้างกว่าความขัดข้องของ Sensor ตัวเดียว ส่วน Switch ต้องพิจารณาต่างกันตามการมีระบบบริหาร การมีวิทยุ พอร์ตที่ใช้ และตำแหน่งใน Architecture
คู่มือ การจัดซื้อ JC-STAR สำหรับภาคการผลิต อธิบายภาพรวมการนำระบบนี้เข้ากระบวนการจัดซื้อ บทความนี้จำกัดขอบเขตที่การพิสูจน์รุ่น FW และ Acceptance Evidence ของ Router, Managed Switch และ IoT Gateway ควรอ่านร่วมกับ แนวทางสร้างเครือข่ายอุตสาหกรรม เพื่อแยกหลักฐานระดับผลิตภัณฑ์ออกจากหลักฐานด้าน Segmentation, Redundancy, สายสัญญาณ และ Monitoring
หลักฐานห้าชุดสำหรับตรวจผลิตภัณฑ์ JC-STAR
1. ใช้ทะเบียนสาธารณะเป็น Source of Truth
ข้อความ “รองรับ” ใน Proposal, Brochure หรือหน้า Reseller ไม่ใช่หลักฐานเพียงพอ เปิดหน้าข้อมูลผลิตภัณฑ์ที่ได้รับฉลากของ IPA แล้วตรวจหมายเลขทะเบียน ระดับ ชื่อผลิตภัณฑ์ รุ่น ผู้ขาย FW ที่ครอบคลุม ข้อมูลอายุ และช่องทางไปยังข้อมูล Security บันทึก URL และวันที่ตรวจในตารางประเมิน ไม่เก็บเพียง Screenshot หรือ PDF การตลาด
2. เทียบรุ่นแบบครบทุกตัวอักษร
ชื่อ Series เดียวกันอาจมี Radio Module, Regional SKU, Power Supply, Port Layout หรือ Hardware Generation ต่างกัน เทียบใบเสนอราคา PO ป้ายกล่อง Nameplate และหน้าจอบริหารด้วย Model String เดียวกัน หาก Distributor ตัด Suffix ออก ต้องให้ผู้ผลิตออกเอกสาร Mapping
3. เทียบเงื่อนไข Firmware
ฉลากไม่ใช่หลักฐานเฉพาะ Hardware อ่านช่วง รุ่นขั้นต่ำ หรือรุ่นเฉพาะของ FW จากทะเบียน แล้วดึงรุ่นจริงจาก Management Interface หรือ Command Output เครื่องที่ผ่าน FAT อาจถูกเปลี่ยนในคลัง เครื่อง RMA อาจมากับ Image เก่า หรือ Factory Reset อาจย้อนกลับอีก Baseline จึงต้องตรวจซ้ำใน SAT และบันทึกใน Asset Register
4. ตรวจอายุและสถานะปัจจุบัน
ทะเบียนที่ใช้ได้ตอนประมูลอาจเปลี่ยนก่อนสั่งจำนวนมาก ซื้อเพิ่ม หรือเปลี่ยนเครื่อง ตรวจซ้ำก่อนอนุมัติสั่งซื้อ ใน FAT ก่อนส่ง ใน SAT และก่อน Repeat Order ใช้ QR เป็นทางเข้าไปยังข้อมูลปัจจุบัน ไม่ใช้รูป QR เป็นหลักฐานด้วยตัวมันเอง
5. อ่านข้อมูล Security และช่องทางติดต่อ
ตรวจช่องทางแจ้งช่องโหว่ วิธีเผยแพร่ Security Advisory วันสิ้นสุด Support ค่าเริ่มต้นที่ปลอดภัย Authentication, Logs และขั้นตอน Update IPA ระบุชัดว่าฉลากไม่รับประกัน Security ที่สมบูรณ์ การเปิด Management Service ออกภายนอก การตั้งค่าที่ไม่แข็งแรง หรือการจัดการ Credential ที่ไม่ดี ยังคงสร้างความเสี่ยงได้

ตัวอย่างทะเบียนสอนอะไรเกี่ยวกับรุ่นและ FW
หน้าผลิตภัณฑ์สาธารณะของ IPA มีตัวอย่าง NEC UNIVERGE IX-R2510, IX-R2520, IX-R2530 และ IX-R2610 โดยมีเงื่อนไข FW 1.5.1 ขึ้นไป และคำแนะนำว่าตอนใช้งานต้องเป็น Version 1.5 ขึ้นไป อีกหน้ามีตัวอย่าง amnimo G/R/X Series โดยมีเงื่อนไข FW V3.4.0
ตัวอย่างเหล่านี้ไม่ใช่การแนะนำให้ซื้อ แต่แสดงวิธีเปลี่ยน “ชื่อ Series” ให้เป็น Configuration ที่ตรวจได้
| จุดตรวจ | ถ้อยคำคลุมเครือ | ถ้อยคำที่ตรวจสอบได้ |
|---|---|---|
| Product | UNIVERGE IX Series | ระบุ IX-R2510/2520/2530/2610 ตัวที่เสนอจริง |
| Firmware | รุ่นล่าสุด | บันทึกรุ่นส่งมอบ เงื่อนไขทะเบียน และ Target ที่อนุมัติ |
| Gateway | amnimo ที่รองรับ | เทียบรุ่น G/R/X และเงื่อนไข V3.4.0 กับหน้าสาธารณะ |
| Evidence | รองรับ JC-STAR | ให้เลขทะเบียน ระดับ URL วันที่ตรวจ และอายุ |
| Operation | Update ตามความจำเป็น | ระบุผู้ตัดสินใจ Test Environment, Rollback และ Deadline |
อย่ารวม “FW 1.5.1 ขึ้นไป” และ “ใช้งานที่ Version 1.5 ขึ้นไป” เป็นคำตอบกว้าง ๆ เพียงเพราะคล้ายกัน ต้องอ่านหน้าปัจจุบัน ตรวจว่า Image ที่ส่งมอบอยู่ในขอบเขตหรือไม่ เลือก Baseline ของโรงงาน และกำหนดผู้ทำ Update เนื่องจากข้อมูลอาจเปลี่ยน ต้องดึงข้อมูลล่าสุดก่อนตัดสินใจสุดท้ายทุกครั้ง
แยก JC-STAR กับ NBTC เป็นคนละ Decision Gate
ฉลาก JC-STAR จากญี่ปุ่นไม่แทนข้อกำหนดสำหรับนำเข้า จำหน่าย ติดตั้ง หรือใช้อุปกรณ์วิทยุและโทรคมนาคมในไทย ต้องพิจารณามาตรฐานเทคนิคของ NBTC การจัดประเภท การจดทะเบียน การรับรอง หรือ SDoC ความถี่ กำลังส่ง เครื่องหมาย และหน้าที่ของผู้นำเข้าตามอุปกรณ์และการใช้งานจริง
เอกสารแปลอังกฤษเพื่ออ้างอิงของประกาศไทยแบ่งอุปกรณ์ที่เกี่ยวข้องเป็นกระบวนการ Class A, Class B และ SDoC กล่าวถึงการทดสอบ การจดทะเบียนหรือรับรอง การเก็บ Supporting Documents เครื่องหมาย และความรับผิดของ Supplier เมื่อมีการเปลี่ยนแปลง เอกสารดังกล่าวเตือนว่าเป็นเพียงคำแปลเพื่อความเข้าใจและไม่แทนฉบับภาษาไทย ในโครงการจริงต้องตรวจฉบับไทยล่าสุด ประเภทอุปกรณ์ ความถี่ และรูปแบบนำเข้ากับผู้รับผิดชอบหรือผู้เชี่ยวชาญในไทย
สิ่งที่ต้องแยกให้ชัด ได้แก่:
- Switch แบบสายล้วนกับอุปกรณ์ที่มี Wi-Fi, LTE/5G หรือ LPWA มีขอบเขตตรวจต่างกัน
- SKU ญี่ปุ่นกับ SKU ไทยอาจต่างกันที่ Module, Frequency, Power และ Label
- นำเข้าชั่วคราว เครื่องทดลอง นำเข้าเชิงพาณิชย์ และฝังในเครื่องจักรผลิตอาจใช้วิธีไม่เหมือนกัน
- Foreign Test Report ไม่ได้หมายความว่า NBTC ยอมรับโดยอัตโนมัติ
- ต้อง Mapping Model String ใน JC-STAR กับรุ่นในหลักฐานไทย
| Gate | คำถามหลัก | หลักฐานทั่วไป | ไม่สามารถแทน |
|---|---|---|---|
| JC-STAR | มีหลักฐาน Product Security ระดับใด | หน้า IPA รุ่น FW เลขทะเบียน อายุ | ภาระ NBTC ในไทย |
| NBTC/ไทย | นำเข้าและใช้ในไทยได้ตามกฎหมายหรือไม่ | ทะเบียน รับรอง SDoC ผลทดสอบ เครื่องหมาย เอกสารผู้นำเข้า | หลักฐาน Security แบบ JC-STAR |
| Factory Design | Architecture ที่ใช้จริงผ่าน Risk Criteria หรือไม่ | Network Diagram, Communication Matrix, Hardening, Risk Assessment | ฉลากใดฉลากหนึ่ง |
| Operation | รักษาการ Update, Monitoring และ Response ได้หรือไม่ | SLA, RACI, Register, SOP, Training | หลักฐานวันรับมอบ |
เปลี่ยนเกณฑ์จัดซื้อ Security ของ IoT ให้เป็น RFP
RFP ต้องบังคับให้ผู้ขายตอบด้วยหลักฐานชุดเดียวกัน ข้อความ “ให้ความสำคัญกับ JC-STAR” หรือ “ส่งมอบ FW ล่าสุด” เปิดโอกาสให้ผู้เสนอใช้สมมติฐานคนละแบบ ควรแยกช่อง Must, Should, Evidence และ Exception
ตารางคำตอบ RFP ที่แนะนำ
| ID | Requirement | คำตอบผู้ขาย | หลักฐานบังคับ | เมื่อมี Exception |
|---|---|---|---|---|
| SEC-01 | ระบุ Model, SKU, HW revision | ค่าและคำอธิบาย | Quote, Datasheet, Nameplate | พักการอนุมัติหากยังไม่ชัด |
| SEC-02 | ระบุสถานะ JC-STAR | ได้แล้ว/ไม่มี/กำลังยื่น | URL, Number, Level, Validity | ตรวจฐานของคำโฆษณา |
| SEC-03 | ระบุ Covered/Delivered FW | Version, Range, Need to update | Public Record และวิธีดึง Version | มีแผนก่อน FAT |
| SEC-04 | อธิบาย Security Update | Process ไม่ใช่คำโฆษณา | PSIRT, Advisory, EOL, Signature | ประเมิน Compensating Control |
| SEC-05 | ให้ Secure Baseline | ปิด Service, Authentication, Keys | Hardening Guide และ Template | วัดจริงใน FAT |
| SEC-06 | ให้ Logging/Time Behavior | Events, Forwarding, Retention | Event List, syslog/API Spec | อนุมัติทางเลือก Monitoring |
| TH-01 | ระบุความสอดคล้องไทย | Class, Number, Owner | เอกสาร NBTC และ Model Mapping | ปิดก่อนนำเข้า |
| TH-02 | ระบุผู้นำเข้า/ผู้รับผิดชอบ Mark | Legal/Operational Owner | Contract, Label, SDoC | ไม่รับหากเจ้าของไม่ชัด |
| OPS-01 | ให้ Update/Rollback Method | Test, Outage, Recovery | SOP, Backup, Signature Check | ซ้อมก่อน SAT |
| OPS-02 | ควบคุม RMA | Model/FW/Evidence | RMA Procedure, Approval Flow | ห้ามแทนรุ่นโดยไม่อนุมัติ |
เลิกใช้คำว่า “Firmware ล่าสุด”
คำว่า “ล่าสุด” เปลี่ยนตามเวลา และรุ่นใหม่อาจยังไม่ผ่าน Compatibility Test กับ OT Application หรือ Driver กำหนด Reference Date, Approved Version, Minimum Version, Prohibited Version, ความสัมพันธ์กับฉลาก การตัดสินช่องโหว่ Deadline และ Test Method หากมีรุ่นใหม่ก่อนส่ง ให้เข้า Change Control ไม่ติดตั้งอัตโนมัติ
กำหนดความสดของหลักฐาน
อย่าถือว่า URL หรือ Certificate ที่ส่งมามีผลตลอดไป ระบุจุดตรวจซ้ำในสัญญา เช่น ภายในจำนวนวันที่กำหนดก่อนอนุมัติซื้อ ก่อนส่ง และใน SAT ปริมาณคำขอ การทดสอบ และเงื่อนไขนำเข้าอาจกระทบต้นทุนและเวลา จึงไม่ควรกำหนด Lead Time มาตรฐานที่ไม่มีฐาน ให้ผู้ขายระบุ Assumption, Exclusion และ Dependency

ข้อกำหนดทดแทนเมื่อไม่พบรุ่นในทะเบียน
การไม่อยู่ในทะเบียนไม่ได้หมายความว่าต้องตัดทิ้งทันที แต่ก็ไม่สามารถใช้ข้อความเดียวว่า “ผู้ผลิตยืนยันว่าปลอดภัย” หรือ “ผ่านมาตรฐานต่างประเทศ” แทนได้ ให้รวม Controls ตามระดับผลกระทบ:
- นโยบาย Secure Development และ Vulnerability Handling ที่เผยแพร่ พร้อม PSIRT Contact
- บังคับเปลี่ยน Default Password, Strong Admin Authentication และ Least Privilege
- ปิด Service ที่ไม่จำเป็น แยก Management Plane จำกัด Source และใช้ Encryption
- Signed Firmware, Authenticity Check, Rollback และ Recovery เมื่อ Update ล้มเหลว
- SBOM หรือข้อมูล Component พร้อม SLA ตอบผลกระทบช่องโหว่
- Audit Log, Time Sync, External Forwarding และ Retention
- ระยะเวลา Security Update, End of Support และ Advisory SLA
- Independent Vulnerability Assessment หรือ Penetration Test พร้อมขอบเขตและผลสรุป
- Segmentation, Jump Host, Communication Allowlist และ Remote Maintenance Control
- หากกำหนดให้ได้ฉลากในอนาคต ต้องมีหลักฐานคำขอและเงื่อนไขเมื่อไม่ได้รับ
Compensating Controls ไม่ใช่การยกเว้น ต้องบันทึก Residual Risk ผู้เป็นเจ้าของ ผู้อนุมัติ และวันหมดอายุ Router ที่ Internet Edge, VPN ข้ามสาขา และ Gateway ที่รวมเครื่องจักรสำคัญควรมีการประเมินอิสระและ Configuration Review ที่เข้มขึ้น ผลทดสอบตัวเครื่องที่ดีไม่ชดเชย Remote Access ถาวรหรือ Shared Admin Account
FAT: ล็อกหลักฐานก่อนส่งมอบ
FAT ต้องพิสูจน์ว่าอุปกรณ์ FW และ Configuration ตามสัญญามีอยู่จริง ไม่ใช่เพียง Demo ว่า Ping ผ่าน ใช้ Model, HW Revision และ FW เดียวกับของส่งจริงเมื่อทำได้
ตรวจเอกสารก่อน FAT
- เทียบ BOM รุ่น จำนวน และ Radio Module กับใบเสนอราคา
- เปิดหน้า IPA ใหม่และเก็บเลขทะเบียน ระดับ FW Condition และ Validity
- ยืนยัน Thai Classification, Registration/Certification/SDoC, Importer และ Marking
- ตรวจแหล่ง FW วิธีตรวจ Signature/Hash และ Release Notes
- อนุมัติ Hardening, Communication Allowlist, Admin Account และ Certificate Process
ทดสอบอุปกรณ์ใน FAT
- เก็บ Model, Serial, Hardware และ Firmware จากตัวเครื่องและหน้าจอบริหาร
- ตรวจการบังคับเปลี่ยน Credential, Service ที่ไม่จำเป็น และ Protocol ที่อนุมัติ
- พิสูจน์ว่า Source ที่ไม่ได้รับอนุญาตเข้า Management Plane ไม่ได้
- สร้าง Failed Login, Configuration Change, Restart และ Update Event แล้วตรวจ Log Export
- ทดสอบ Backup, Restore, FW Update และ Rollback ในระบบที่ควบคุมได้
- ตัด WAN/Cloud แล้วดู Degraded Operation และ Resynchronization
- เทียบ Packet จริงกับ Communication Matrix และสอบสวนปลายทางหรือ Port ที่ไม่แจ้ง
FAT Package ต้องมีวันที่ ผู้ทดสอบ Serial, Screen/Command Output, Baseline, Logs, Exceptions และ Retest Result ช่อง Pass/Fail อย่างเดียวพิสูจน์ไม่ได้ว่าเครื่องที่ถึงไทยคือเครื่องที่ทดสอบ
รักษา Evidence Chain ผ่านการขนส่งและการซื้อในไทย
ถ้าทดสอบในญี่ปุ่นแล้วนำเข้าไทย ให้ผูก FAT Record กับ Serial ใน Shipment ใส่ Model, Serial, Quantity และเอกสารความสอดคล้องใน Packing File และกำหนด Customs/Importer Responsibility ในสัญญา อย่าใช้การถือเครื่องทดลองเข้าประเทศแล้วเปลี่ยนเป็นใช้งานผลิตจริงโดยไม่มีการตรวจรูปแบบนำเข้าและวัตถุประสงค์
หากซื้อในไทย อย่าสั่งเพียงชื่อ Series ที่สำนักงานใหญ่อนุมัติ ตรวจ Thailand SKU, Local Mark, Warranty, Delivered FW และ RMA Stock ในประเทศ “Equivalent Product” ต้องกลับไปตรวจ Model, Function, JC-STAR, NBTC, FW และ Support ก่อนอนุมัติ
SAT: ปิดความต่างของไซต์จริง
SAT เทียบ FAT Package กับเครื่องส่งมอบ แล้วทดสอบ Power, WAN, DNS, NTP, Identity, Monitoring, Firewall, Cloud และ Maintenance Access ในโรงงานไทย
| SAT Check | ตัวอย่าง Acceptance | หลักฐานที่เก็บ |
|---|---|---|
| Physical Identity | Model, Serial, HW, FW ตรงกับที่อนุมัติ | Nameplate Photo, Output, BOM |
| JC-STAR Status | หน้า Current, Validity และ FW ใช้ได้ | URL, Timestamp, PDF |
| Thai Conformity | เอกสาร/เครื่องหมายตรงกับรุ่นจริง | Number, Document, Label Photo |
| Management Plane | เข้าได้จาก VLAN/Source ที่อนุมัติเท่านั้น | Firewall Log, Reachability Test |
| Time/Logging | Sync NTP และส่งเข้า Monitoring | Time Offset, Event Record |
| Remote Support | ปิดเป็นค่าเริ่มต้น เปิดแบบอนุมัติและมี Expiry | Request, Connection Log, Closure |
| Recovery | Restore และเปลี่ยน Spare แล้วต่อกลับได้ | Procedure, Duration, Delta, Result |
| Change Control | ความต่างจาก FAT ได้อนุมัติแล้ว | Delta List, Approval |
หากต้องเปลี่ยน FW ใน SAT อย่าตัดสินเพียงว่าอยู่ในเงื่อนไขฉลากหรือไม่ รวม Backup, Signature Check, Compatibility, Downtime, Rollback, Log และ Regression Test ใน Change Record เดียวกัน ราคาและเวลาขึ้นกับรุ่น การเชื่อมต่อ เวลาหยุดที่อนุญาต และขอบเขตทดสอบ จึงต้องเสนอราคาตาม Assumption ของโครงการ

ส่งมอบสู่ Operation: ทำให้เป็น Lifecycle Control
หลังรับมอบ โรงงานต้องมี RACI และ Asset Register ที่บอกว่าใครตรวจอะไรเมื่อใด อย่าให้ฝ่ายจัดซื้อรู้ URL แต่ฝ่าย Operation ไม่รู้เงื่อนไข Model/FW
ฟิลด์ขั้นต่ำใน Asset Register
- Asset ID, Location, Function, Criticality และ Network Zone
- Manufacturer, Product, Model, SKU, HW Revision และ Serial
- JC-STAR Number, Level, URL, Validity และ Last Review
- Approved/Running/Prohibited FW, Update History และ Next Review
- Thai Conformity Number/Class, Document Location และ Importer
- Management Address/Method, Account Owner และ Certificate Owner
- Configuration Backup, Restore, Spare และ RMA Terms
- PSIRT, Support Contact, EOL/EOS และ Advisory Recipient
- Exception, Compensating Control, Approver และ Expiry
Workflow การตัดสิน FW
เมื่อได้รับ Advisory ให้ตรวจว่ารุ่นและ FW ตรงหรือไม่ ฟังก์ชันนั้นเปิดอยู่หรือไม่ เข้าถึงได้จากไหน และเงื่อนไขการโจมตีคืออะไร จากนั้นเลือกการลดความเสี่ยงฉุกเฉิน ทดสอบ Update อนุมัติหยุดระบบ Deploy ตรวจ Function และอัปเดต Register แม้รุ่นใหม่ยังอยู่ในเงื่อนไขทะเบียนก็ต้องทดสอบ Compatibility และ Configuration
Validity, Support Status และข้อกำหนดไทยต้อง Review ตามรอบ และตรวจซ้ำก่อนซื้อเพิ่ม RMA เปลี่ยน FW เปลี่ยน Use Case หรือย้ายโรงงาน ไม่คัดลอก Approval เก่าโดยไม่ประเมินใหม่
แยกคะแนนความแข็งแรงของหลักฐานออกจาก Residual Risk
ถ้าให้คะแนนฉลากมากเกินไป ผลิตภัณฑ์ที่มีฉลากแต่ Support สั้นหรือ SKU ใช้ในไทยไม่ได้อาจชนะ ควรแยกแกนดังนี้
| แกนประเมิน | สิ่งที่ดู | ข้อควรระวัง |
|---|---|---|
| Product Evidence | JC-STAR Level, Model, FW, Validity | ลดคะแนนคำตอบเฉพาะ Series |
| Thai Conformity | NBTC, Import, Marking, Local SKU | “ตรวจภายหลัง” ไม่ควรได้เต็ม |
| Technical Controls | Auth, Encryption, Logs, Updates, Isolation | ให้คะแนน Testability ไม่ใช่ Checkbox |
| Lifecycle | PSIRT, Update Period, EOL, RMA | แยก Warranty จาก Security Support |
| Delivery | FAT/SAT, Documents, Local Support | ดูว่าใครปิด Exception |
| Residual Risk | Exposure, Concentration, Compensation | ไม่ซ่อน Risk Approval ในคะแนนราคา |
TCO ต้องรวม Local Conformity, Test, Configuration, Monitoring, Update, Downtime, Spare, RMA และ Retirement ไม่ใช่เฉพาะราคาซื้อ ไม่มีราคาและ Lead Time มาตรฐานที่เชื่อถือได้ ต้องเทียบ Quote ภายใต้ Quantity, Radio Function, Import Path, Test Depth, Downtime และ Compatibility Assumption เดียวกัน
ความผิดพลาดที่พบบ่อย
คิดว่าทุกรุ่นใน Series ได้รับฉลาก
เทียบ Model, Suffix, HW Revision และ FW แบบตรงกัน และแนบ Mapping ของผู้ผลิตในสัญญาเมื่อจำเป็น
เก็บแค่รูป QR
เปิดหน้าสาธารณะ ตรวจ Number, Level, Model, FW, Validity และเก็บ URL/เวลาเข้าถึง
มองข้ามการเปลี่ยนเครื่องหลัง FAT
ผูก Serial กับ Shipment และตรวจซ้ำใน SAT ใช้ Approval Flow เดียวกันกับ RMA
ใช้ JC-STAR แทนข้อกำหนดไทย
NBTC และการตรวจไทยเป็น Gate แยก ตรวจ Radio, Frequency, Import Scenario และ Local SKU ตามกฎปัจจุบัน
เชื่อว่า FW ใหม่ปลอดภัยกว่าเสมอ
ตรวจ Conformity, Vulnerability Fix, Compatibility, Migration และ Rollback แยกกัน ควบคุม Approved Version ไม่ใช่คำว่า Latest
ส่งให้ Operation แค่ URL
ส่ง Asset Register, Advisory Route, Update SOP, Spare, Exception Expiry และ RACI พร้อมซ้อม Restore/RMA
FAQ: การจัดซื้ออุปกรณ์เครือข่าย JC-STAR
มี JC-STAR แล้วใช้ในโรงงานไทยได้ทันทีหรือไม่?
ไม่ได้ JC-STAR ไม่แทน NBTC หรือข้อกำหนดไทย ตรวจ Security Record ของ Model/FW และตรวจ Class, Import, Registration/Certification/SDoC, Marking และ Thailand SKU แยกกัน
ต้องเลือกผลิตภัณฑ์ที่มีดาวมากที่สุดหรือไม่?
เลือกตาม Use Case และ Risk ★1/★2 เป็น Self-declaration ส่วน ★3/★4 ใช้ Third-party Assessment แต่ Architecture, Configuration, Operation, Thai Conformity และ Support Life ยังสำคัญ
ต้องตรวจ FW ของ IoT Gateway อย่างไร?
บันทึกเงื่อนไขทะเบียน รุ่นส่งมอบ Factory Baseline รุ่นห้ามใช้ Target, Signature, Compatibility และ Rollback ตัวอย่าง amnimo G/R/X ที่มีเงื่อนไข V3.4.0 แสดงว่าต้องจับคู่ Series กับ FW
ตัวอย่าง NEC UNIVERGE IX-R2510 ใช้ FW ใด?
ทะเบียนตัวอย่างที่อ้างถึงครอบคลุม IX-R2510/2520/2530/2610 ที่ FW 1.5.1 ขึ้นไป และมีคำแนะนำให้ใช้ Version 1.5 ขึ้นไป ต้องตรวจหน้าปัจจุบันของ IPA และข้อมูลผู้ผลิตอีกครั้งก่อนสั่ง
ไม่พบรุ่นในทะเบียนต้องตัดทิ้งหรือไม่?
ไม่จำเป็นเสมอไป ตั้ง Compensating Requirements ด้าน PSIRT, Secure Update, Authentication, Logs, SBOM, Independent Test, Segmentation และ Support แล้วอนุมัติ Residual Risk อย่างชัดเจน
ประเมินคำตอบ “กำลังยื่น JC-STAR” อย่างไร?
แยกจากฉลากที่ได้รับจริง ตรวจประเภทและฐานของหมายเลขจาก IPA และเนื่องจาก IPA แจ้งความล่าช้า จึงไม่ควรสมมติวันได้ฉลาก กำหนด Substitute, Hold Point หรือ Contract Remedy
FAT และ SAT ต้องตรวจซ้ำหรือไม่?
ต้องตรวจ FAT ล็อก Configuration ก่อนส่ง ส่วน SAT ตรวจ Serial, FW, Local Mark, Network Setting, Logs และ Remote Access ของเครื่องจริง การขนส่ง การแทน Stock และ Site Change อาจทำให้ Evidence Chain ขาด
มีงบและเวลามาตรฐานหรือไม่?
ไม่มีตัวเลขเดียวที่น่าเชื่อถือ รุ่น จำนวน Radio Function รูปแบบนำเข้า Scope Test เวลาหยุด และระบบเดิมทำให้ต่างกัน ขอ Quote ที่ระบุ Assumption, Exclusion, Evidence และ Retest Condition
สรุป: เชื่อมหลักฐานจัดซื้อถึงการปฏิบัติการ
การจัดหาอุปกรณ์เครือข่าย JC-STAR ต้องตรวจรุ่นที่ถูกต้อง เงื่อนไข FW หมายเลข ระดับ หน้าปลายทางของ QR และ Validity ไม่ใช่เพียงรูปฉลากหรือชื่อ Series ในประเทศไทยต้องตรวจ NBTC และข้อกำหนดท้องถิ่นแยกกัน JC-STAR ไม่สามารถแทนได้ จัดรูปแบบหลักฐานใน RFP ล็อกใน FAT ผูก Serial ผ่านการขนส่ง ตรวจซ้ำใน SAT และส่งเข้าสู่ Asset Register กับ Update Workflow
TOMAS TECH สามารถช่วยได้ตั้งแต่ช่วงที่ยังไม่เลือกรุ่น ตั้งแต่ RFP Evidence Matrix, การตรวจ Thailand SKU และ Network Architecture ไปจนถึง FAT/SAT Cases และทะเบียนส่งมอบ สามารถติดต่อเราได้ตั้งแต่ระยะกำหนด Requirements
แหล่งอ้างอิง
- IPA “JC-STAR” — ภาพรวม วิธีประเมิน ประวัติอัปเดตปี 2026 และประกาศความล่าช้า
https://www.ipa.go.jp/security/jc-star/index.html
- IPA “การยื่นใหม่ระดับ ★1 และ ★2” — เริ่มรับคำขอ ★1 เมื่อ 25 มีนาคม 2025 และเปลี่ยนวิธีขอหมายเลข 22 เมษายน 2026
https://www.ipa.go.jp/security/jc-star/shinsei/shinki-1-2/index.html
- IPA ข้อมูลรายละเอียด JC-STAR
https://www.ipa.go.jp/security/jc-star/detail.html
- IPA วิธีตรวจฉลาก
https://www.ipa.go.jp/security/jc-star/label-description.html
- IPA เกณฑ์และวิธีประเมินระดับ ★1
https://www.ipa.go.jp/security/jc-star/tekigou-kizyun-guide/label1/index.html
- IPA ระเบียบและข้อกำหนดที่เกี่ยวข้อง
https://www.ipa.go.jp/security/jc-star/kitei.html
- METI ที่มาด้านนโยบายของระบบประเมินความปลอดภัยผลิตภัณฑ์ IoT
- IPA ทะเบียนตัวอย่าง NEC UNIVERGE IX-R2510/2520/2530/2610
https://jc-star.ipa.go.jp/conformance/CNF_019c788d-013b-731f-9eda-f539ae8e83a6.html
- IPA ทะเบียนตัวอย่าง amnimo G/R/X Series
https://jc-star.ipa.go.jp/conformance/CNF_019b34a2-42c2-7280-aeae-5694c6f97c78.html
- NBTC “Conformity Assessment of Telecommunication Equipment” คำแปลอังกฤษเพื่ออ้างอิง
https://standard1.nbtc.go.th/getattachment/2583af14-e879-4b21-8295-5789f34492ec/e8001.aspx
*บทความนี้อ้างอิงข้อมูลสาธารณะที่ตรวจ ณ วันที่ 2 กันยายน 2026 และเป็นแนวทางจัดซื้อทั่วไป ไม่ใช่คำแนะนำด้านกฎหมาย ศุลกากร หรือการรับรอง ระบบ ทะเบียน ประเภทอุปกรณ์ และกฎอาจเปลี่ยนแปลง โปรดตรวจข้อมูลล่าสุดกับ IPA, NBTC หน่วยงานที่มีอำนาจ และผู้เชี่ยวชาญก่อนสั่งซื้อ นำเข้า และใช้งานจริง*