การยอมรับฉลากความปลอดภัยไซเบอร์ร่วมกันสำหรับการจัดซื้อ IoT โรงงานอาเซียน

การยอมรับ Cybersecurity Labelling Scheme ร่วมกันระหว่าง Singapore CLS และ JC-STAR STAR-1 ของญี่ปุ่น ช่วยให้นำผลการตรวจข้อกำหนดที่ทั้งสองโครงการถือว่าเทียบเท่ากันมาใช้ซ้ำในการยื่นขอฉลากอีกฝ่ายได้ ผู้ผลิตจึงลดงานประเมินความสอดคล้องที่ซ้ำซ้อนเมื่อเข้าสู่หลายตลาด แต่สำหรับผู้ซื้อในโรงงาน ฉลากไม่ได้หมายความว่าอุปกรณ์ได้รับอนุญาตให้เชื่อมต่อเครือข่ายการผลิต ไม่ได้แปลว่าสองโครงการเหมือนกันทุกประการ และไม่ใช่ข้อบังคับทางกฎหมายของประเทศไทย บทความนี้เปลี่ยนหลักฐานจากฉลากให้เป็นประตูกำกับการจัดซื้อครบวงจร: RFP → จับคู่หลักฐาน → ความเหมาะสมกับสินทรัพย์และโซน → การแก้ไขโดยซัพพลายเออร์ → FAT/SAT → ติดตามอายุและการเปลี่ยนแปลง

ข้อตกลงญี่ปุ่น–สิงคโปร์เปลี่ยนอะไร

กระทรวงเศรษฐกิจ การค้าและอุตสาหกรรมของญี่ปุ่นกับ Cyber Security Agency of Singapore ลงนาม Memorandum of Cooperation เมื่อ 18 มีนาคม 2026 และเริ่มมีผลเมื่อ 1 มิถุนายน 2026 ขอบเขตคือข้อกำหนดที่ได้รับการยอมรับว่าเทียบเท่ากันระหว่าง JC-STAR STAR-1 กับ Singapore CLS Level 1 พร้อมช่องทางยื่นขอที่กระชับขึ้นสำหรับอีกโครงการหนึ่ง (METI, ประกาศ CSA)

IPA อธิบายว่าผลิตภัณฑ์ที่มีฉลาก CLS ซึ่งยื่นขอ JC-STAR ★1 สามารถยกเว้นรายการใน checklist ที่ตรงกับข้อกำหนดซึ่งผ่านการตรวจภายใต้ CLS แล้ว ค่าธรรมเนียม STAR-1 สำหรับเส้นทางผลิตภัณฑ์ CLS คือ 140,000 เยนรวมภาษี เทียบกับค่าธรรมเนียมมาตรฐาน 198,000 เยนรวมภาษี และอายุฉลาก JC-STAR ครั้งแรกคือ 2 ปี ตัวเลขเหล่านี้เป็นเงื่อนไขการยื่นขอโครงการ ไม่ใช่ต้นทุนรวมของการประเมินโรงงาน การทดสอบ การเชื่อมระบบ การแปล หรือการปรับเครือข่าย (แนวทาง IPA)

คุณค่าที่แท้จริงไม่ใช่ “ไม่ต้องประเมิน” แต่คือการลดงานซ้ำแล้วนำเวลาไปตรวจความเสี่ยงเฉพาะโรงงาน

การยอมรับร่วมกันไม่ใช่ความเท่าเทียมอัตโนมัติ

คำว่า mutual recognition อาจทำให้เข้าใจผิดว่าฉลาก A เปลี่ยนเป็นฉลาก B ได้ทันที แต่คำอธิบายของ IPA ระบุแคบกว่านั้น: ผลิตภัณฑ์ที่สอดคล้องกับ CLS ถือว่าผ่านเกณฑ์ JC-STAR ★1 บางส่วน และรายการที่ตรงกันอาจได้รับการยกเว้น ผู้สมัครยังต้องดำเนินตามช่องทางที่กำหนด ระบุผลิตภัณฑ์และฉลาก และส่งหลักฐานสำหรับข้อกำหนดที่ยังเหลือหรือสอดคล้องเพียงบางส่วน การยื่นจาก JC-STAR ไป CLS ก็ต้องยื่นผ่านช่องทาง MRA เช่นกัน

ผู้ซื้อไม่ควรยอมรับข้อความสั้น ๆ ว่า “รองรับ CLS/JC-STAR” ในใบเสนอราคา ควรขอข้อมูลต่อผลิตภัณฑ์ดังนี้

• ชื่อโครงการ ระดับ หมายเลขฉลาก และ URL สาธารณะสำหรับตรวจสอบ
• ผู้สมัคร/ผู้ผลิต และความสัมพันธ์กับซัพพลายเออร์ตามสัญญา
• ชื่อสินค้า รุ่น hardware revision เฟิร์มแวร์ และบริการคลาวด์ที่เกี่ยวข้อง
• วันที่ออก วันหมดอายุ และสถานะการต่ออายุ
• ข้อกำหนดที่ใช้ซ้ำผ่าน MRA และข้อกำหนดที่ยังต้องส่งหลักฐาน
• ช่องทางแจ้งช่องโหว่ ระยะเวลาสนับสนุนอัปเดต และวิธีแจ้งเตือน
• เงื่อนไขประเมินใหม่เมื่อเปลี่ยนชิ้นส่วน OEM เฟิร์มแวร์ หรือคลาวด์

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

อย่ารวม Singapore CLS Level 1–4 เป็นสิ่งเดียวกัน

Singapore CLS มี 4 ระดับและสะสมขั้นการประเมินมากขึ้นตามระดับ CSA อธิบายว่า Tier 1 เป็น baseline อิง ETSI EN 303 645, Tier 2 เป็นการปฏิบัติตามข้อกำหนดบังคับของมาตรฐาน, Tier 3 ครอบคลุมวงจรพัฒนาและวิเคราะห์ซอฟต์แวร์ไบนารี และ Tier 4 เป็น penetration testing โดยห้องปฏิบัติการทดสอบ (CSA สำหรับผู้ผลิต)

ดังนั้นห้ามอธิบายว่า CLS Level 1 คือผลิตภัณฑ์ที่ผ่าน penetration test โดยบุคคลที่สาม ขั้นดังกล่าวอยู่ที่ Level/Tier 4 และแม้ Level 4 ก็ไม่ได้รับประกันว่าจะปลอดภัยจากการโจมตีทุกแบบหรือทุกโครงสร้างโรงงาน แต่เป็นหลักฐานภายใต้รุ่น ขอบเขต และเงื่อนไขทดสอบที่กำหนด

ข้อกำหนด STAR-3 ที่เผยแพร่เดือนกรกฎาคม 2026 เป็นอีกประเด็นหนึ่ง

IPA ประกาศเมื่อ 13 กรกฎาคม 2026 ว่าได้เผยแพร่ข้อกำหนด STAR-3 สำหรับอุปกรณ์เครือข่ายและกล้องเครือข่ายแล้ว (IPA JC-STAR) เรื่องนี้สำคัญต่อโรงงานที่ซื้อ router, gateway และกล้อง แต่แยกจากการยอมรับ STAR-1/CLS Level 1 ที่เริ่มเดือนมิถุนายน 2026

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

ดูการออกแบบหลักฐานเฉพาะสินค้าได้จากคู่มือจัดซื้อกล้องเครือข่ายตาม JC-STAR และคู่มือยื่นขอ JC-STAR

เกณฑ์จัดซื้อความปลอดภัย IoT ต้องเป็น “ฉลาก + ความเหมาะสมกับโรงงาน”

ETSI EN 303 645 V3.1.3 เป็น baseline ด้านความปลอดภัยและการคุ้มครองข้อมูลสำหรับ consumer IoT ตัวมาตรฐานระบุว่าการนำไปใช้ขึ้นกับ risk assessment และ threat modelling และบางกรณีควรเพิ่มข้อกำหนด นอกจากนี้มาตรฐานกำหนดข้อกำหนดผลิตภัณฑ์ แต่ไม่ได้กำหนดวิธีทดสอบหรือรับรองสากลแบบเดียวสำหรับทุกบริบท (ETSI EN 303 645)

ขอบเขตนี้สำคัญต่อโรงงาน Baseline ช่วยตรวจรหัสผ่านเริ่มต้น กระบวนการรายงานช่องโหว่ และการอัปเดต แต่โรงงานต้องเพิ่ม availability, safety, maintenance window, โปรโตคอลอุตสาหกรรม อายุสินทรัพย์ remote access และการเชื่อมกับ PLC เดิม

แม้ gateway มีฉลาก ก็ควรถูกปฏิเสธหรือแก้ไขหาก:

• หน้าจอบริหารเข้าถึงได้จากทั้งเครือข่ายผลิต
• ไม่ระบุปลายทางคลาวด์ ทิศทาง พอร์ต DNS หรือการต่ออายุ certificate
• อัปเดตอัตโนมัติอาจหยุดสายการผลิตเมื่อใดก็ได้
• ไม่มี backup/restore ของ configuration
• มีแต่ shared administrator และระบุผู้ปฏิบัติงานไม่ได้
• ประกาศช่องโหว่ส่งถึงสำนักงานใหญ่แต่ไม่ถึงทีมซ่อมบำรุงไทย
• ระยะสนับสนุนสั้นกว่าอายุใช้งานอุปกรณ์

ฉลากคือจุดเริ่มต้นของหลักฐาน baseline ส่วนการยอมรับความเสี่ยงโรงงานคือประตูสุดท้ายของสภาพแวดล้อมจริง

กระบวนการจัดซื้อ IoT โรงงานต่างประเทศแบบ 6 ประตู

อย่าแยกการตรวจฉลากเป็นงานเอกสารลอย ๆ ให้หลักฐานไหลผ่านทั้งกระบวนการและกำหนดว่าใครตรวจอะไร ใครอนุมัติข้อยกเว้น

Gate 1: ระบุรูปแบบคำตอบใน RFP

อย่าเขียนเพียง “รองรับ JC-STAR หรือ CLS” ให้กำหนดช่องคำตอบ เอกสารแนบ และระดับ mandatory/conditional/information

คำตอบ Yes/No ไม่มีหลักฐานไม่เพียงพอ ต้องบันทึกเวอร์ชันเอกสาร รุ่นที่ใช้ และข้อยกเว้นข้างคำตอบทุกครั้ง ข้อที่ไม่ตอบให้ถือว่า “ยังไม่ยืนยัน” ไม่ใช่ผ่าน

Gate 2: จับคู่หลักฐานโครงการกับข้อกำหนดบริษัท

จับคู่ข้อกำหนดภายในกับหลักฐานจากโครงการ หลักฐานซัพพลายเออร์ หรือการทดสอบโรงงาน จุดประสงค์ไม่ใช่บังคับให้ทุกอย่าง 1:1 แต่เพื่อแสดงว่าข้อสรุปมาจากไหนและอะไรยังเปิดอยู่

ตารางควรมี requirement ID, risk, scheme clause, evidence, covered version, decision, exception, due date และ approver ระบุหน้า/หัวข้อ ผู้ออก และวันที่ ไม่เก็บเพียงชื่อไฟล์

Gate 3: ตัดสินความเหมาะสมกับสินทรัพย์และโซน

เซนเซอร์เดียวกันอาจเสี่ยงต่ำในห้องประชุม แต่มีผลสูงเมื่อ gateway เข้าถึง controller การผลิต ระบุสินทรัพย์ เส้นทางเชื่อม ข้อมูล อำนาจควบคุม ผลหยุดงาน เป้าหมายกู้คืน และความสามารถทีมท้องถิ่น

ถามอย่างเป็นรูปธรรมว่าหากอุปกรณ์ถูกเจาะจะเกิดอะไร: ข้อมูล monitor หาย ค่าเท็จเข้า MES วิดีโอรั่ว การตั้งค่าถูกเปลี่ยน ผู้โจมตีเคลื่อนสู่ PLC หรือคลาวด์ล่มแล้วใช้งานไม่ได้ จากนั้นจำกัดเส้นทางด้วย segmentation, allow-list, OT DMZ, jump host, local fallback, backup และ monitoring

ดูเกณฑ์เพิ่มได้ในคู่มือเลือก Industrial IoT Gateway สถานะฉลากกับตำแหน่งใน OT zone เป็นคนละการอนุมัติ

Gate 4: ปิดการแก้ไขของซัพพลายเออร์ก่อนทำสัญญา

ข้อความ “ค่อยคุยตอนติดตั้ง” คือความเสี่ยงด้านราคาและกำหนดส่ง แต่ละรายการต้องมี owner, deliverable, due date, retest และผลเมื่อส่งไม่ครบ หากแก้สินค้าไม่ได้ ให้ประเมิน compensating control แบบมีวันทบทวน

ตัวอย่างคือ VLAN เฉพาะ, firewall allow-list, outbound-only cloud, jump host, เปิด remote access เฉพาะช่วง, external monitoring และ spare unit แต่อย่าใช้เครือข่ายปกปิดปัญหาพื้นฐานตลอดไป เช่นไม่มี security update ไม่มีช่องทางรับแจ้งช่องโหว่ หรือเปลี่ยน shared password ไม่ได้ ต้องระบุ residual-risk owner และวันทบทวน

Gate 5: เชื่อม FAT กับ SAT ในบันทึกรับมอบเดียวกัน

FAT ตรวจสินค้า การตั้งค่า และเอกสารก่อนส่งหรือในสภาพแวดล้อมผู้ขาย SAT ตรวจเครือข่ายจริง identity, time, monitoring และ failure mode ของโรงงาน DNS, NTP, proxy, certificate, VLAN และการออกคลาวด์ทำให้อุปกรณ์ที่ผ่าน FAT มีพฤติกรรมต่างเมื่อหน้างานได้

อย่างน้อยให้ทดสอบ:

1. รุ่น HW/FW ขอบเขตฉลาก และ backup ตรงกัน
2. เปลี่ยน default credential มี named account, least privilege และ MFA ตามขอบเขต
3. traffic ที่อนุญาตใช้งานได้และ traffic ต้องห้ามถูกบล็อก
4. ความแท้จริง/ครบถ้วนของ update และการกู้เมื่อ update ล้มเหลว
5. time sync, event log, forwarding, retention และ alert
6. พฤติกรรมปลอดภัยเมื่อ cloud/WAN ล่ม
7. factory reset, restore และเปลี่ยน spare unit
8. remote access ผ่านขอ อนุมัติ เปิด หมดอายุ และบันทึก
9. ซ้อมรับประกาศช่องโหว่และ escalation ฉุกเฉิน
10. ลงชื่อ open item, interim control, due date และผู้อนุมัติสุดท้าย

เก็บ input, expected result, actual result, log, version, ผู้ทดสอบ และวันที่ ผลผ่านที่ทำซ้ำไม่ได้ไม่มีประโยชน์ต่อ audit หรือ incident response

Gate 6: ติดตามวันหมดอายุและการเปลี่ยนแปลง

อายุ JC-STAR ครั้งแรก 2 ปีต้องเชื่อมกับ asset register ไม่ใช่อยู่ในแฟ้มจัดซื้อ ติดตามการต่ออายุ firmware, EOL, vulnerability และ cloud change เริ่ม review ก่อนหมดอายุตาม lead time ที่องค์กรกำหนด เพื่อขอหลักฐานใหม่ ประเมินทางเลือก เพิ่ม control หรือวางแผนถอด

ติดตามมากกว่าฉลาก:

• เฟิร์มแวร์ที่ติดตั้ง/อนุมัติ
• vendor advisory, CVE และประกาศฉุกเฉิน
• สถานะฉลาก รุ่นที่ครอบคลุม และเงื่อนไข MRA
• product/component change และ end of support
• cloud endpoint, certificate, API และเงื่อนไขข้อมูล
• การย้ายโซน เปลี่ยนการใช้งาน หรือเพิ่ม external connection
• การเปลี่ยน supplier, distributor หรือ OEM

กำหนดล่วงหน้าว่าการเปลี่ยนแบบใดใช้ desk review, partial SAT, full reassessment หรือ disconnect ทันที

ตัวอย่าง: นำ IoT gateway ที่มีฉลากเข้าโรงงานไทย

สมมติโครงการใช้ gateway ที่ได้ Singapore CLS Level 1 เพื่อติดตามการเดินเครื่องในไทย ตัวอย่างนี้แสดงขั้นตอน ไม่ใช่ผลประเมินผลิตภัณฑ์จริง Gate 1 ให้จัดซื้อขอทะเบียนฉลาก รุ่น/เฟิร์มแวร์/คลาวด์ และระยะอัปเดต เมื่อเอกสารไม่กล่าวถึง LTE module ที่จะเพิ่ม ทีมบันทึก configuration นั้นว่า “ยังไม่ยืนยัน” ไม่ปฏิเสธทั้งผลิตภัณฑ์และไม่ให้ผ่านเพราะ base unit มีฉลาก

Gate 2 แยก scheme baseline, traffic specification และ remote-access requirement ของโรงงาน หลักฐานเรื่อง authentication/update ไม่ตอบ SIM management, mobile network, cloud endpoint หรือ local escalation หาก traffic sheet ใช้ wildcard ต้องแตกเป็น FQDN, port, direction และ certificate check ที่จำเป็น Gate 3 ยืนยันว่า gateway อ่านสถานะ PLC แต่ไม่ส่ง control command อย่างไรก็ตามเพราะแบบเดิมต่อ switch เดียวกัน จึงกำหนด monitoring VLAN, firewall, OT-DMZ relay และ jump host เป็นเงื่อนไข PLC ต้องทำงานต่อเมื่อ cloud ล่ม และ buffer เต็มต้องไม่กระทบ control traffic

Gate 4 ปิด configuration ที่รวม LTE, update contact, การตอบครั้งแรกในไทย และขั้นตอนต่อ certificate ก่อนสัญญา FAT ตรวจ firmware, traffic, account, signed update และ restore ส่วน SAT ทดสอบซ้ำกับ DNS, NTP, VLAN, firewall, proxy และ monitoring จริง รวม WAN loss, cloud outage, certificate error, restart และ buffer limit Gate 6 เชื่อมอายุฉลาก 2 ปี firmware, LTE, cloud API, certificate, SIM และสัญญาตัวแทนเข้ากับ asset ID เดียว ต่อฉลากแล้วไม่ได้แปลว่า build ที่เปลี่ยนยังอยู่ในขอบเขต และฉลากยังมีผลก็ไม่ได้ยกเว้น review เมื่อ cloud API เปลี่ยน

ออกแบบทะเบียนหลักฐานด้วยผลิตภัณฑ์ รุ่น สถานที่ และคำตัดสิน

การเก็บ PDF/อีเมลใน folder ไม่เพียงพอเมื่อมีหลายโรงงาน ทะเบียนควรเชื่อม manufacturer/model/HW/FW, scheme/level/number/URL/expiry, factory/line/zone/use, traffic/identity, decision/exception/residual-risk owner, lifecycle notice และ FAT/SAT ใช้ key ของ product build ที่ไม่ซ้ำและเชื่อม asset ID เพื่อไล่จากฉลากไปถึงเครื่องจริง การทดสอบ ข้อยกเว้น และ update ได้

ทุกคำตัดสินมีเวลา ให้เก็บ decision date, assessed version, next review และ change trigger ร่วมกัน จัดซื้อดูขอบเขตเชิงพาณิชย์และ change/EOL; วิศวกรรมดู function/FAT; IT/OT security ดู evidence, traffic และ zone fit; ซ่อมบำรุงดู update/recovery/SAT; กฎหมายและคุณภาพดู warranty/record; asset owner ยอมรับ residual risk ทะเบียนเดียวช่วยไม่ให้แต่ละฝ่ายสร้างหลักฐานชุดเดิมซ้ำ

ข้อควรระวังเมื่อนำไปใช้ในโรงงานไทย

บทความนี้ไม่ได้กล่าวว่าข้อตกลงญี่ปุ่น–สิงคโปร์เป็นข้อบังคับทางกฎหมายของไทย บริษัทอาจกำหนดฉลากเป็นนโยบายจัดซื้อ เงื่อนไขลูกค้า หรือข้อกำหนดตลาดส่งออกได้ แต่ต้องแยกจากหน้าที่ตามกฎหมายไทย ตรวจหมวดสินค้าและกฎที่ใช้จริงต่างหาก และใช้ CLS/JC-STAR เป็นหลักฐานความปลอดภัยหนึ่งชุด

ภาษาปฏิบัติงานก็เป็น control หากหลักฐานเป็นอังกฤษ/ญี่ปุ่น แต่ช่างไทยใช้ขั้นตอน isolate, update หรือ restore ไม่ได้ control จะล้มเหลวเมื่อเกิดเหตุ ต้องแปล runbook และ emergency contact และทดสอบกับผู้ปฏิบัติงานจริง ในการแปลให้แยก label, certification, conformity และ factory acceptance ไม่ใช้คำว่า “รับรอง” แทนทุกอย่าง

ต้องทำ commercial chain ให้ชัดด้วย ผู้ผลิต brand owner ผู้ยื่นฉลาก ผู้นำเข้าญี่ปุ่น distributor ไทย local SIer และ cloud operator อาจเป็นคนละบริษัท สัญญาต้องระบุว่าใครส่ง advisory ใครตอบก่อน ใครเก็บอะไหล่ และใครช่วยกู้ระบบเมื่อเปลี่ยนตัวแทนจำหน่าย

10 คำถามสำหรับประชุมตัดสินการจัดซื้อ

1. ฉลากเป็นโครงการและระดับใด ตรวจจากข้อมูลสาธารณะได้หรือไม่
2. รุ่น HW/FW และ cloud ที่ส่งมอบตรงขอบเขตฉลากหรือไม่
3. ข้อกำหนดใดใช้ซ้ำผ่าน MRA และหลักฐานอะไรยังเหลือ
4. ฉลากหมดอายุเมื่อไร ใครรับผิดชอบต่ออายุ
5. ช่องทางช่องโหว่และระยะอัปเดตรองรับอายุเครื่องหรือไม่
6. endpoint, port, identity, crypto, certificate และ remote access มีเอกสารหรือไม่
7. หากถูกโจมตีหรือหยุดใน OT zone นี้ โรงงานรับผลได้หรือไม่
8. รวมต้นทุนและภาระของ compensating control ในการเทียบสินค้าแล้วหรือยัง
9. สัญญากำหนด FAT/SAT fail, remediate, retest และผู้รับผิดชอบกำหนดส่งหรือไม่
10. asset register ติดตาม expiry, vulnerability และ change หลัง go-live ได้หรือไม่

คำตอบ “ค่อยตรวจหลังติดตั้ง” คือความไม่แน่นอนด้านต้นทุนและเวลา ควรปิดก่อนสั่งซื้อหรือบันทึก conditional approval พร้อมงบ วันครบกำหนด และ risk owner

ความผิดพลาดที่พบบ่อยและวิธีแก้

รับภาพฉลากโดยไม่ตรวจรุ่นและเวอร์ชัน

เทียบทะเบียนสาธารณะ ขอบเขตฉลาก BOM ส่งมอบ และ release note บันทึกรุ่นจริงตอนรับของและใน asset register

อธิบาย mutual recognition ว่าเปลี่ยนฉลากอัตโนมัติ

ใช้ถ้อยคำว่า “การยื่นขอแบบกระชับโดยใช้ผลตรวจข้อกำหนดเทียบเท่าซ้ำ” และเก็บขั้นตอนยื่น เอกสาร ค่าธรรมเนียม review และออกฉลากที่ยังเหลือ

เข้าใจว่า CLS Level 1 ผ่าน penetration test

ตรวจคำอธิบาย Level/Tier ของ CSA การทดสอบโดยห้องปฏิบัติการอยู่ Level/Tier 4 หาก use case ต้องการให้จ้างทดสอบเพิ่มโดยระบุ scope และ version

ใช้ฉลากแทนการอนุมัติต่อโรงงาน

ทดสอบ asset/zone fit, traffic, account, update, failure behavior และ monitoring ให้ factory owner เป็นผู้ยอมรับ residual risk

เก็บ expiry และ EOL ไว้ในแฟ้มจัดซื้อ

เชื่อม asset, contract, vulnerability และ maintenance ด้วย product ID เดียว ส่ง alert ไป role mailbox หรือ ticket ไม่ผูกกับพนักงานคนเดียว

ใช้เอกสารสำนักงานใหญ่แทนการปฏิบัติงานไทย

เตรียมขั้นตอนภาษาไทย escalation, restore drill, spare และ permission ให้สำนักงานใหญ่ดู scheme evidence ส่วนโรงงานดู operating evidence พร้อมจุดส่งมอบชัดเจน

FAQ เรื่องการยอมรับฉลากความปลอดภัยไซเบอร์ร่วมกัน

มี JC-STAR แล้วได้ Singapore CLS อัตโนมัติหรือไม่

ไม่ การยอมรับร่วมกันช่วยใช้ผลตรวจข้อกำหนดเทียบเท่าซ้ำและลดขั้นตอน แต่ยังต้องยื่นตามช่องทางของอีกโครงการและส่งเอกสารที่เหลือ

ค่าธรรมเนียม JC-STAR STAR-1 สำหรับผลิตภัณฑ์ CLS เท่าไร

IPA ระบุ 140,000 เยนรวมภาษี เทียบกับมาตรฐาน 198,000 เยนรวมภาษี นี่คือค่าธรรมเนียมยื่นขอ ไม่รวมการเตรียมหลักฐาน ทดสอบโรงงาน ปรับเครือข่าย หรือแปล

ฉลาก JC-STAR ครั้งแรกมีอายุกี่ปี

IPA ระบุ 2 ปี ให้บันทึกฉลาก รุ่นที่ครอบคลุม และวันหมดอายุใน asset register และทบทวนเมื่อมีการเปลี่ยนสำคัญแม้ยังไม่หมดอายุ

Singapore CLS Level 1 ผ่าน penetration test หรือไม่

ไม่ควรสรุปเช่นนั้น CSA กำหนด penetration testing โดยห้องปฏิบัติการไว้ที่ Level/Tier 4 ต้องตรวจระดับและขอบเขตจริง

โรงงานไทยจำเป็นต้องมี JC-STAR หรือ CLS ตามกฎหมายหรือไม่

บทความนี้ไม่ได้ระบุข้อบังคับดังกล่าว ตรวจนโยบายบริษัท สัญญาลูกค้า ตลาดส่งออก หมวดสินค้า และกฎหมายที่ใช้แยกกัน

Gateway มีฉลากแล้วต่อเข้าผลิตได้ทันทีหรือไม่

ไม่ได้ ต้องประเมินสินทรัพย์ traffic, privilege, update, outage, monitoring และ recovery และใช้ OT DMZ หรือ control อื่นเมื่อจำเป็น

สรุป: นำเวลาที่ลดงานซ้ำไปตรวจความเสี่ยงเฉพาะโรงงาน

การยอมรับ Cybersecurity Labelling Scheme ร่วมกันช่วยใช้ผลการประเมินข้อกำหนดระหว่าง JC-STAR STAR-1 และ Singapore CLS Level 1 ซ้ำได้ แต่ไม่ใช่ความเท่าเทียมทั้งหมดโดยอัตโนมัติ ไม่ใช่สิทธิ์ต่อเครือข่ายโรงงาน และไม่ใช่ข้อบังคับไทย ผลลัพธ์เกิดเมื่อสร้างสายโซ่หลักฐานตั้งแต่ RFP, mapping ตาม version, asset/zone fit, remediation, FAT/SAT จนถึง expiry/change monitoring แล้วนำเวลาที่ประหยัดจากงานซ้ำไปตรวจ uptime, safety, remote support และการทำงานจริงของทีมท้องถิ่น

TOMAS TECH สนับสนุนการจัดซื้อ IoT โรงงานต่างประเทศตั้งแต่ระยะต้น ทั้งจัดโครง RFP จับคู่ฉลากกับหลักฐาน ตรวจความเหมาะสมของเครือข่าย OT และออกแบบรายการ FAT/SAT หากกำลังแยกข้อกำหนดการยื่นฉลากออกจากเงื่อนไขรับมอบโรงงาน สามารถปรึกษาได้ทางหน้าติดต่อ

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

• IPA: ขั้นตอน mutual recognition
• METI: ข้อตกลงญี่ปุ่น–สิงคโปร์
• CSA: ประกาศ 18 มีนาคม 2026
• IPA: ข้อมูล JC-STAR
• CSA: ภาพรวม CLS
• CSA: CLS สำหรับผู้ผลิต
• ETSI EN 303 645 V3.1.3