CONNECTED PRODUCT SECURITY
EU Cyber Resilience Act: แบรนด์ไทยต้องเตรียมรายงานช่องโหว่อย่างไร ก่อน 11 กันยายน 2026
คู่มือเตรียม EU Cyber Resilience Act สำหรับแบรนด์ไทย ผู้ผลิต OEM และผู้ส่งออกสินค้าเชื่อมต่อ ครบ Scope, 24–72 ชั่วโมง, SRP, PSIRT และแผนพร้อมใช้ 30 วัน

ANSWER FIRST
สรุปคำตอบ
ประเด็นสำคัญ
- เส้นตายรายงาน Article 14 เริ่ม 11 กันยายน 2026 ก่อนข้อกำหนดหลักของ CRA ที่ใช้ 11 ธันวาคม 2027
- แบรนด์ที่ให้ผู้อื่นผลิตแต่ขายภายใต้ชื่อหรือเครื่องหมายการค้าของตนอาจมีบทบาทเป็น Manufacturer ตาม CRA
- Early Warning 24 ชั่วโมงและ Notification 72 ชั่วโมงต้องเริ่มนับจากเวลาที่องค์กรรับรู้เหตุ จึงต้องมีหลักฐานและผู้ตัดสินใจตลอด 24/7
- รายงานผ่าน Single Reporting Platform ครั้งเดียว แต่ต้องรู้ Assigned Representative, CSIRT ที่เกี่ยวข้อง และประเทศที่สินค้าถูกวางจำหน่าย
- ใช้ 30 วันทำ Product Register, PSIRT Playbook, Vulnerability Intake, SBOM Readiness และ Tabletop Exercise ก่อนเหตุจริง
เส้นตายกันยายน 2026 เปลี่ยน Cybersecurity ให้เป็นหน้าที่ของแบรนด์
Regulation (EU) 2024/2847 หรือ Cyber Resilience Act มีผลบังคับใช้ตั้งแต่ 10 ธันวาคม 2024 ข้อกำหนดหลักจะใช้ตั้งแต่ 11 ธันวาคม 2027 แต่ Article 14 เรื่องการรายงานเริ่มก่อนในวันที่ 11 กันยายน 2026 นั่นหมายความว่าองค์กรอาจยังอยู่ระหว่างเตรียม Secure-by-Design, Technical Documentation หรือ Conformity Assessment แต่เมื่อพบเหตุที่เข้าเกณฑ์ต้องมีระบบรับรู้ ประเมิน และรายงานที่ทำงานได้แล้ว
คณะกรรมาธิการยุโรประบุว่าหน้าที่นี้ครอบคลุมผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัลซึ่งถูกทำให้มีอยู่ในตลาด EU รวมถึงสินค้าที่เข้าตลาดก่อนข้อกำหนดหลักเดือนธันวาคม 2027 หากยังถูกทำให้มีอยู่ในตลาด แบรนด์จึงไม่ควรจำกัดโครงการไว้เฉพาะรุ่นใหม่ แต่ต้องทำ Installed Base และ Market Availability Map ของรุ่นเดิม ช่องทางจำหน่าย และประเทศที่เกี่ยวข้องด้วย
ตรวจ Product Scope และบทบาท Manufacturer ก่อนออกแบบ Workflow
CRA ใช้กับซอฟต์แวร์หรือฮาร์ดแวร์และ Remote Data Processing ที่เกี่ยวข้อง เมื่อ Intended Purpose หรือการใช้งานที่คาดการณ์ได้อย่างสมเหตุสมผลมีการเชื่อมข้อมูลทางกายภาพหรือตรรกะกับอุปกรณ์หรือเครือข่าย ตัวอย่างทางธุรกิจอาจรวม Smart Appliance, Router, Wearable, Connected Toy, Industrial IoT, แอปที่เป็นส่วนสำคัญของสินค้า และบริการ Cloud ที่หากไม่มีแล้วฟังก์ชันหนึ่งของผลิตภัณฑ์ทำงานไม่ได้ อย่างไรก็ดี สินค้าบางกลุ่มอยู่ภายใต้กฎหมายเฉพาะและถูกยกเว้น เช่น Medical Devices ตามกฎหมาย EU ที่ CRA ระบุไว้ จึงต้องทำ Scope รายรุ่น ไม่ใช้คำว่า “สินค้าอิเล็กทรอนิกส์ทั้งหมด” แบบกว้างเกินจริง
สำหรับธุรกิจ OEM–ODM จุดที่มักเข้าใจผิดคือโรงงานผู้พัฒนาหรือประกอบสินค้าไม่ใช่ผู้รับผิดชอบเพียงรายเดียว นิยาม Manufacturer ครอบคลุมบุคคลหรือนิติบุคคลที่พัฒนา ผลิต หรือให้ผู้อื่นพัฒนาและผลิต แล้วทำตลาดภายใต้ชื่อหรือเครื่องหมายการค้าของตน ผู้นำเข้าหรือผู้จัดจำหน่ายที่ขายภายใต้แบรนด์ตนเองหรือดัดแปลงสินค้าอย่างมีนัยสำคัญก็อาจถูกถือเป็นผู้ผลิตได้
สร้าง CRA Product Register อย่างน้อยให้มี Product Family, Model, Hardware Revision, Firmware หรือ Software Version, Cloud Dependency, Brand Owner, Legal Manufacturer, EU Importer, Authorised Representative, ประเทศและช่องทางขาย, จำนวนสินค้าที่เกี่ยวข้อง, Support Period, Vulnerability Contact และเจ้าของ Technical File หากตอบช่องใดไม่ได้ ให้ถือเป็นช่องว่างที่ต้องปิดก่อนออกแบบระบบรายงาน
แยกเหตุที่ต้องรายงาน และควบคุมนาฬิกา 24–72 ชั่วโมง
CRA กำหนดเหตุหลักสองกลุ่ม กลุ่มแรกคือ Actively Exploited Vulnerability ซึ่งมีหลักฐานน่าเชื่อถือว่าผู้ไม่หวังดีกำลังใช้ช่องโหว่นั้นโจมตีจริง กลุ่มที่สองคือ Severe Incident ที่กระทบความปลอดภัยของผลิตภัณฑ์อย่างร้ายแรง เช่น กระทบ Availability, Authenticity, Integrity หรือ Confidentiality ของข้อมูลหรือฟังก์ชันสำคัญ หรือทำให้มีโค้ดอันตรายเข้าไปทำงานในผลิตภัณฑ์หรือระบบของผู้ใช้ การพบช่องโหว่ทุกครั้งจึงไม่เท่ากับต้องรายงานแบบบังคับ แต่ทุกครั้งต้องเข้าสู่กระบวนการประเมินที่มีหลักฐาน
เมื่อรับรู้เหตุที่เข้าเกณฑ์ ผู้ผลิตต้องส่ง Early Warning โดยไม่ชักช้าและไม่เกิน 24 ชั่วโมง จากนั้นส่ง Vulnerability หรือ Incident Notification ภายใน 72 ชั่วโมงพร้อมข้อมูลที่มี เช่น ผลิตภัณฑ์ ลักษณะเหตุ มาตรการแก้ไขหรือบรรเทา และสิ่งที่ผู้ใช้ทำได้ รายงานสุดท้ายสำหรับช่องโหว่ที่ถูกใช้โจมตีต้องส่งไม่เกิน 14 วันหลังมาตรการแก้ไขหรือบรรเทาพร้อมใช้งาน ส่วนเหตุการณ์ร้ายแรงต้องส่งภายในหนึ่งเดือนจากการส่งข้อมูล 72 ชั่วโมง
องค์กรจึงต้องนิยาม Awareness Time ว่าเวลาใดถือว่าบริษัทรับรู้ ใครมีอำนาจจัดประเภทเหตุ และใครอนุมัติรายงาน อย่าปล่อยให้ Ticket อยู่ใน Inbox ช่วงวันหยุดโดยไม่มีเจ้าของ ตั้ง Severity Matrix, Escalation Tree, Legal Review แบบเร่งด่วน และ Decision Log ที่บันทึกเวลา หลักฐาน เหตุผล และผู้อนุมัติ เพราะเวลา 24 ชั่วโมงไม่เพียงพอสำหรับการเริ่มหาข้อมูลผลิตภัณฑ์หลังเกิดเหตุ
- 0–4 ชั่วโมง: ยืนยันผู้รับผิดชอบ เก็บหลักฐาน และผูกเหตุเข้ากับรุ่นหรือเวอร์ชัน
- 4–12 ชั่วโมง: ประเมินเกณฑ์ Actively Exploited หรือ Severe Incident และประเทศที่สินค้าอยู่ในตลาด
- 12–20 ชั่วโมง: เตรียม Early Warning, ตรวจความละเอียดอ่อนของข้อมูล และอนุมัติโดยผู้มีอำนาจ
- ก่อน 24 ชั่วโมง: ส่งผ่าน SRP เก็บหลักฐานการส่ง และเปิด Workstream สำหรับรายงาน 72 ชั่วโมง
เตรียม Single Reporting Platform และผู้แทนก่อนเกิดเหตุจริง
ENISA จัดทำ CRA Single Reporting Platform หรือ SRP เป็นจุดรายงานกลาง ผู้ผลิตรายงานครั้งเดียวและเลือก CSIRT ที่ทำหน้าที่ประสานตามหลักเกณฑ์ของ CRA ข้อมูลจะส่งถึง CSIRT และ ENISA ตามระบบ โดยแพลตฟอร์มมีกำหนดใช้งานสำหรับหน้าที่บังคับตั้งแต่ 11 กันยายน 2026 ENISA เผยแพร่คู่มือการลงทะเบียน Assigned Representative และการส่งหรืออัปเดตรายงานแล้วเมื่อ 31 กรกฎาคม 2026 พร้อมระบุว่าคู่มืออาจปรับปรุงได้ จึงต้องตรวจเวอร์ชันล่าสุดก่อนใช้งาน
อย่ารอให้เกิดเหตุแล้วค่อยตัดสินใจว่าใครจะกดส่ง กำหนด Primary และ Secondary Assigned Representative อย่างน้อยสองคน แยกคนจัดทำข้อมูล คนอนุมัติ และคนส่งเมื่อทำได้ จัดการสิทธิ์แบบ Least Privilege แต่มีความต่อเนื่องเมื่อบุคลากรลาออก ลาพัก หรืออยู่นอกเวลาทำการ เก็บ Contact List ของ CSIRT, Importer, Distributor, Cloud Provider, Security Researcher และที่ปรึกษากฎหมายไว้ใน Playbook เดียวกัน
ใช้แผน 30 วันเปลี่ยน Compliance ให้เป็น Product Security Operating System
วันที่ 1–7 ให้ผู้บริหารแต่งตั้ง CRA Owner และ PSIRT Lead ทำ Product Scope, Market Map และ RACI ระหว่าง Brand Owner, OEM, Software Vendor, Importer และ Distributor เปิดช่องทางรับแจ้งช่องโหว่ที่หาเจอง่ายและมีเจ้าของตลอดเวลา พร้อมกำหนดนโยบาย Coordinated Vulnerability Disclosure ที่ไม่ขัดขวางนักวิจัยความปลอดภัยที่รายงานโดยสุจริต
วันที่ 8–15 สร้าง Intake Form, Severity Matrix, Awareness Rule, 24–72 Hour Timeline, Notification Template และ Customer Communication Template เชื่อมข้อมูลจาก Bug Tracker, SOC, Customer Service, Warranty, Cloud Monitoring และคู่ค้าเข้าสู่ Case ID เดียวกัน กำหนดว่าข้อมูลใดเผยแพร่ได้ ข้อมูลใดต้องจำกัดสิทธิ์ และข้อมูลใดต้องตรวจ Legal หรือ Privacy ก่อนส่ง
วันที่ 16–23 ลงทะเบียนและทดสอบบทบาทบน SRP ตามคู่มือล่าสุดของ ENISA จัดทำ Product Data Pack สำหรับรุ่นสำคัญ และเริ่ม SBOM Readiness โดยระบุองค์ประกอบซอฟต์แวร์กับความสัมพันธ์ของ Supply Chain อย่างน้อยระดับ Top-level Dependencies เป้าหมายไม่ใช่ทำเอกสารเพื่อ Audit เท่านั้น แต่ต้องใช้ค้นหาว่าสินค้ารุ่นใดได้รับผลกระทบเมื่อพบช่องโหว่ใน Component หนึ่ง
วันที่ 24–30 ทำ Tabletop Exercise ด้วยสถานการณ์จำลอง เช่น Firmware Library ถูกใช้โจมตีจริงในช่วงคืนวันศุกร์ วัดเวลาตั้งแต่รับแจ้งถึงตัดสินใจ ส่ง Early Warning เตรียมรายงาน 72 ชั่วโมง อนุมัติ Patch และแจ้งผู้ใช้ ปิด Exercise ด้วย Gap List, Owner และ Due Date จากนั้นรายงานผู้บริหารเฉพาะความเสี่ยงที่กระทบความต่อเนื่อง รายได้ ลูกค้า และความสามารถในการส่งออก
อย่าหยุดที่การรายงาน: เตรียม Secure-by-Design สำหรับปี 2027
การรายงานคือด่านเร่งด่วน แต่ CRA วางข้อกำหนดตลอดวงจรผลิตภัณฑ์ ผู้ผลิตต้องประเมินความเสี่ยงไซเบอร์ ออกแบบ พัฒนา ผลิต ส่งมอบ และดูแลช่องโหว่ตามความเสี่ยง ผลิตภัณฑ์ควรเข้าสู่ตลาดโดยไม่มีช่องโหว่ที่รู้ว่าใช้โจมตีได้ ใช้ค่าเริ่มต้นที่ปลอดภัย มีการอัปเดตอย่างเหมาะสม และให้ข้อมูลการติดตั้งหรือใช้งานอย่างปลอดภัย
กฎหมายกำหนด Support Period โดยหลักอย่างน้อยห้าปี เว้นแต่คาดว่าผลิตภัณฑ์จะใช้งานสั้นกว่านั้น และต้องสื่อสารวันสิ้นสุด Support อย่างเข้าใจง่าย การตั้งราคาสินค้าโดยไม่คิดต้นทุน Patch, Cloud, Monitoring, Incident Response และบุคลากรตลอด Support Period อาจสร้างภาระกำไรในอนาคต ฝ่ายการเงินจึงควรนำ Cybersecurity Lifecycle Cost เข้า Product P&L และสัญญา OEM ตั้งแต่การเสนอราคา
สื่อสารกับผู้ใช้โดยรักษาทั้งความปลอดภัยและความเชื่อมั่น
เมื่อรับรู้ช่องโหว่ที่ถูกใช้โจมตีหรือเหตุการณ์ร้ายแรง ผู้ผลิตต้องแจ้งผู้ใช้ที่ได้รับผลกระทบ และเมื่อเหมาะสมต้องแจ้งผู้ใช้ทั้งหมด พร้อมมาตรการบรรเทาหรือแก้ไขที่ทำได้ การแจ้งเร็วแต่คลุมเครืออาจทำให้ลูกค้าไม่รู้ว่าต้องทำอะไร ขณะที่การเปิดรายละเอียดทางเทคนิคมากเกินไปก่อน Patch พร้อมอาจเพิ่มความเสี่ยง จึงต้องมี Communication Decision Matrix ที่ผ่านการทบทวนร่วมกันระหว่าง Security, Legal, Customer Service และ Brand
ข้อความควรตอบให้ได้ว่าสินค้าและเวอร์ชันใดได้รับผลกระทบ ผู้ใช้ตรวจสอบรุ่นได้อย่างไร ความเสี่ยงคืออะไรโดยไม่ขยายเกินหลักฐาน ต้องทำอะไรทันที Patch จะมาเมื่อไร มีทางเลือกใดหากอัปเดตไม่ได้ และติดต่อที่ไหน ใช้หน้า Security Advisory ที่มี URL คงที่ วันที่และ Version ชัดเจน รองรับ Mobile และ Accessibility และเชื่อมกับ Email, In-app Notification, Distributor และ Call Center ด้วยข้อความต้นทางเดียวกัน
ความน่าเชื่อถือไม่ได้เกิดจากการประกาศว่า “ปลอดภัย 100%” แต่เกิดจากการยอมรับข้อเท็จจริง อธิบายการตัดสินใจ และส่งมอบการแก้ไขตามเวลา วัด Mean Time to Acknowledge, Time to Triage, 24h/72h On-time Rate, Patch Availability, Affected Product Identification Accuracy, User Update Adoption และ Repeat Incident Rate ควบคู่กับ Contact Volume และ Sentiment เพื่อให้ทีมเห็นทั้ง Cyber Risk และ Brand Impact ใน Dashboard เดียว
VERIFIED SOURCES
แหล่งข้อมูลอ้างอิง
- European Commission — Cyber Resilience Act reporting obligations (updated 31 July 2026)
- ENISA — CRA Single Reporting Platform, FAQs and user guidance (updated 31 July 2026)
- European Commission — Practical guidance on the Cyber Resilience Act (27 July 2026)
- EUR-Lex — Regulation (EU) 2024/2847, Cyber Resilience Act
BRAND × INSPIRE × ACTION



