
HPE อุด 72 ช่องโหว่ Aruba Wi-Fi มี 8 จุดคะแนนเต็ม องค์กรควรเช็กด่วน
HPE ออกอัปเดตแก้ช่องโหว่ 72 รายการใน ArubaOS โดยมี 8 รายการได้คะแนนความรุนแรงสูงสุด 10.0 และครอบคลุมซอฟต์แวร์ AOS-8 กับ AOS-10 ที่ใช้กับระบบ Wi-Fi องค์กร ตามรายงานวันที่ 23 ตุลาคม 2026 ของ BleepingComputer เรื่องนี้จึงควรอยู่ในรายการงานของคนดูแลเครือข่าย และในรายการติดตามของคนที่ต้องรับผิดชอบเมื่อพนักงานทำงานผ่าน Wi-Fi ไม่ได้ครับ
ArubaOS หรือ AOS คือซอฟต์แวร์ระบบที่ทำให้อุปกรณ์เครือข่าย Aruba ทำงาน ประกาศ HPE ระบุทั้งอุปกรณ์ควบคุมเครือข่าย เกตเวย์ที่จัดการผ่านระบบส่วนกลาง และจุดกระจาย Wi-Fi ในกลุ่มที่เกี่ยวข้อง โดยบางช่องโหว่อาจเปิดทางให้คนภายนอกสั่งงานอุปกรณ์โดยไม่ต้องมีบัญชีผู้ใช้มาก่อน (HPE) สำหรับคนที่ไม่ได้เป็นฝ่ายไอที ประเด็นคือควรมีคนตรวจอุปกรณ์ส่วนกลางเหล่านี้ด้วย การอัปเดตมือถือหรือโน้ตบุ๊กของตัวเองไม่ได้ตอบคำถามว่าอุปกรณ์เครือข่ายได้รับการแก้ไขแล้วหรือยัง
สรุป 30 วินาที: เกิดอะไรขึ้น
HPE เผยแพร่ประกาศความปลอดภัย HPESBNW05162 ฉบับแก้ไขครั้งที่ 1 วันที่ 22 ตุลาคม 2026 จัดระดับโดยรวมเป็น Critical หรือร้ายแรง และแนะนำให้ลูกค้าติดตั้งแพตช์ ซึ่งหมายถึงอัปเดตที่ใช้แก้ข้อบกพร่องด้านความปลอดภัยโดยเร็ว เนื่องจากปัญหามีความซับซ้อน ครอบคลุมกว้าง และมีผลกระทบสูง (HPE)
แปดรายการที่ได้คะแนนเต็มมีทั้งปัญหาข้ามขั้นตอนยืนยันตัวตน และปัญหาที่นำไปสู่การสั่งให้เครื่องรันคำสั่งจากระยะไกล โดย BleepingComputer ระบุว่าการโจมตีกลุ่มนี้ไม่ต้องมีสิทธิ์เดิม ไม่ต้องรอผู้ใช้กดอะไร และมีความซับซ้อนต่ำ (BleepingComputer) คะแนน CVSS คือคะแนนประเมินความรุนแรงของช่องโหว่ ใช้ช่วยจัดลำดับความเร่งด่วน ไม่ควรอ่านคะแนนเต็มว่าเป็นหลักฐานว่าองค์กรของเราถูกเจาะแล้ว
ฝั่ง Canadian Centre for Cyber Security ออกคำเตือน AV26-1079 ซึ่งในตัวประกาศลงวันที่ 22 ตุลาคม 2026 ระบุรุ่นซอฟต์แวร์ที่ต้องตรวจ และขอให้ผู้ใช้กับผู้ดูแลติดตั้งอัปเดตที่จำเป็น (Canadian Centre for Cyber Security) จึงมีทั้งคำแนะนำจากผู้ผลิตและคำเตือนจากหน่วยงานความมั่นคงไซเบอร์ให้หยิบเรื่องนี้มาดำเนินการ
ทำไมเรื่องนี้เกี่ยวกับคุณ
รายชื่อที่ HPE ระบุมี Mobility Conductors และ Mobility Controllers ซึ่งเป็นอุปกรณ์จัดการและควบคุมระบบเครือข่าย รวมถึง Mobility Gateways ที่จัดการผ่าน HPE Networking Central ซึ่งเป็นระบบจัดการส่วนกลาง อีกสองกลุ่มคือ AOS-10 Access Points และ AOS-8 Instant Access Points หรือจุดกระจายสัญญาณ Wi-Fi (HPE) คนตรวจจึงต้องดูมากกว่ากล่องกระจายสัญญาณที่มองเห็นบนเพดาน
ถ้าคุณทำงานในสำนักงาน โรงแรม โรงพยาบาล มหาวิทยาลัย หรือห้าง และหน่วยงานใช้ Aruba กลุ่มนี้ คำแนะนำของผมคือส่งเรื่องให้คนดูแลตรวจรุ่นจริง ธุรกิจในไทยที่ใช้ผลิตภัณฑ์ดังกล่าวก็ควรเช็กเช่นกัน แต่แหล่งข้อมูลชุดนี้ไม่ได้บอกว่ามีองค์กรไทยกี่แห่งใช้งานหรือได้รับผลกระทบ จึงยังสรุปขอบเขตในไทยไม่ได้
ความเสี่ยงที่ผู้ผลิตอธิบายไม่ได้หยุดอยู่ที่การเชื่อมต่อช้า บางรายการอาจทำให้ผู้โจมตีได้สิทธิ์ผู้ดูแล เปลี่ยนการตั้งค่า และเข้าถึงหรือแก้ไขข้อมูลอ่อนไหว ขณะที่บางรายการอาจทำให้อุปกรณ์ถูกยึดควบคุมทั้งหมด (HPE) ในมุมการทำงาน ผมจึงอยากให้ผู้จัดการถามถึงความพร้อมของเครือข่ายที่ทีมต้องพึ่ง มากกว่ารอให้มีคนรายงานว่า Wi-Fi ใช้ไม่ได้ก่อน
สำหรับพนักงาน นักศึกษา หรือผู้ปกครองที่เป็นเพียงผู้ใช้เครือข่าย งานที่เหมาะคือแจ้งผู้รับผิดชอบพร้อมชื่อประกาศ ไม่จำเป็นต้องลองทดสอบช่องโหว่เอง และไม่ควรตีความว่าการเห็นชื่อ Aruba หมายถึงอุปกรณ์ทุกชิ้นมีปัญหา เพราะ HPE กำหนดขอบเขตตามผลิตภัณฑ์และรุ่นซอฟต์แวร์ที่ระบุไว้ (HPE)
ทำงานยังไง
การข้ามขั้นตอนยืนยันตัวตน หมายถึงระบบยอมให้ทำสิ่งที่ตามปกติต้องตรวจสิทธิ์ก่อน ส่วน Remote Code Execution หรือ RCE คือการทำให้เครื่องปลายทางรันคำสั่งจากระยะไกล ในประกาศนี้ HPE อธิบายผลที่อาจเกิดขึ้นตั้งแต่ได้สิทธิ์ผู้ดูแลไปจนถึงรันคำสั่งบนระบบปฏิบัติการของอุปกรณ์ ซึ่งเป็นซอฟต์แวร์หลักที่ควบคุมการทำงานของเครื่อง (HPE)
ลองนึกถึง ตู้ควบคุมไฟกลางของห้าง ครับ คนเดินห้างเห็นเพียงไฟตามจุดต่าง ๆ แต่คนที่ควบคุมตู้กลางได้อาจเปลี่ยนการทำงานของพื้นที่ที่ตู้รับผิดชอบ อุปกรณ์ควบคุม Wi-Fi ก็มีความสำคัญในลักษณะนี้ ผลกระทบจริงต้องดูว่าอุปกรณ์นั้นดูแลเครือข่ายส่วนไหน การยึดเครื่องหนึ่งจึงเป็นเหตุให้ต้องประเมินขอบเขตต่อ แต่ยังไม่ใช่หลักฐานว่าทุกระบบในองค์กรถูกยึดไปด้วย
HPE ระบุช่องโหว่คะแนน 10.0 เป็น CVE-2026-79844, CVE-2026-79845, CVE-2026-79846, CVE-2026-79847, CVE-2026-79848, CVE-2026-79849, CVE-2026-79850 และ CVE-2026-79851 โดย CVE คือรหัสอ้างอิงช่องโหว่ที่ช่วยให้คนดูแลกับผู้ขายคุยถึงปัญหาเดียวกันได้ (HPE) สำหรับผู้อ่านทั่วไปไม่จำเป็นต้องจำครบ แต่ฝ่ายไอทีควรผูกงานแก้ไขกับเลขประกาศและรุ่นอุปกรณ์ให้ชัด
มีข้อจำกัดที่ต้องอ่านด้วย: คำอธิบายของ CVE-2026-79844 และ CVE-2026-79846 ระบุว่าต้องมีเงื่อนไขบางอย่างที่อยู่นอกการควบคุมของผู้โจมตี แต่ HPE ไม่ได้แจกแจงเงื่อนไขเหล่านั้นในข้อความที่ให้มา (HPE) จึงไม่ควรเดาเองว่าการตั้งค่าขององค์กรทำให้ปลอดภัยแล้ว และก็ไม่ควรพูดว่าทุกเครื่องถูกโจมตีได้เหมือนกันโดยไม่มีเงื่อนไข
จุดสังเกต: มีแพตช์แล้ว แต่ต้องเลือกให้ตรงสายรุ่น
สิ่งที่นำไปใช้ได้ทันทีคือตารางรุ่นแก้ไข ไม่ใช่เพียงข่าวว่ามีอัปเดตใหม่ HPE กำหนดรุ่นที่ได้รับผลกระทบและรุ่นแก้ไขแยกตามสายซอฟต์แวร์ดังนี้ (HPE)
| สายซอฟต์แวร์ | รุ่นที่อยู่ในขอบเขตปัญหา | รุ่นแก้ไขในสายนั้น |
|---|---|---|
| AOS-10.8.x.x | 10.8.1.1 และต่ำกว่า | 10.8.1.2 ขึ้นไป |
| AOS-10.7.x.x | 10.7.2.6 และต่ำกว่า | 10.7.2.7 ขึ้นไป |
| AOS-10.4.x.x | 10.4.1.13 และต่ำกว่า | 10.4.1.14 ขึ้นไป |
| AOS-8.13.x.x | 8.13.3.0 และต่ำกว่า | 8.13.3.1 ขึ้นไป |
| AOS-8.10.x.x | 8.10.0.23 และต่ำกว่า | 8.10.0.24 ขึ้นไป |
คำว่า “ขึ้นไป” ในตารางต้องอ่านคู่กับสายรุ่นนั้น ไม่ควรหยิบตัวเลขจากคนละแถวมาตัดสินแทนกัน คำเตือนของแคนาดาก็ระบุเกณฑ์รุ่น 10.8.1.2, 10.7.2.7, 10.4.1.14, 8.13.3.1 และ 8.10.0.24 ตรงกัน (Canadian Centre for Cyber Security) ผมแนะนำให้บันทึกรุ่นก่อนและหลังอัปเดตไว้กับอุปกรณ์แต่ละตัว จะตรวจงานต่อได้ง่ายกว่าคำว่า “อัปแล้วครับ” เพียงอย่างเดียว
อีกจุดคือซอฟต์แวร์เก่า HPE ระบุว่ารุ่นที่ถึง End of Maintenance หรือสิ้นสุดการบำรุงรักษา ให้สันนิษฐานว่าได้รับผลกระทบเว้นแต่จะระบุเป็นอย่างอื่น และไม่ได้อยู่ในความครอบคลุมของประกาศ ส่วนรุ่นที่ผ่าน End of Support หรือสิ้นสุดการสนับสนุน ผู้ผลิตยังไม่ได้ประเมินความเสี่ยง จึงให้ถือว่าอาจได้รับผลกระทบและควรย้ายไปใช้รุ่นที่ยังรองรับ (HPE) การไม่เจอรุ่นเก่าในตารางจึงไม่ใช่คำรับรองว่าปลอดภัย
เรื่องเงิน / ผลกระทบ
แหล่งข่าวชุดนี้ไม่มีตัวเลขความเสียหาย ค่าแรงอัปเกรด ราคาอุปกรณ์ทดแทน หรือค่าใช้จ่ายในไทย ผมจึงไม่ประเมินออกมาเป็นเงินบาท สิ่งที่ผู้ผลิตยืนยันได้คือผลทางเทคนิคบางรายการอาจถึงขั้นเปลี่ยนการตั้งค่า เข้าถึงข้อมูลอ่อนไหว หรือยึดควบคุมอุปกรณ์ได้ (HPE) ส่วนผลต่อรายได้และเวลาทำงานของแต่ละแห่งต้องประเมินจากการใช้งานจริง
สำหรับเจ้าของกิจการ ผมเสนอให้แยกงานที่ต้องจัดเวลาออกเป็นการตรวจรายการเครื่อง การเตรียมและติดตั้งอัปเดต และการตรวจบริการหลังทำเสร็จ หากมีเครื่องที่หมดการสนับสนุน ให้ขอผู้ดูแลเสนอทางเลือกย้ายรุ่นพร้อมผลต่อการใช้งาน อย่าเพิ่งสรุปว่าต้องซื้ออุปกรณ์ใหม่ทั้งหมด เพราะประกาศนี้ให้คำแนะนำเรื่องซอฟต์แวร์ที่รองรับ แต่ไม่ได้ให้ข้อสรุปเรื่องการจัดซื้อของแต่ละองค์กร (HPE)
อีกเรื่องที่ควรตกลงคือช่วงเวลาหยุดปรับปรุงระบบ ผมแนะนำให้ผู้จัดการระบุว่าช่วงไหนกระทบงานน้อย ใครแจ้งผู้ใช้ และใครตรวจรับงาน การมีชื่อผู้รับผิดชอบกับหลักฐานรุ่นหลังอัปเดตทำให้การใช้เวลาของทีมตรวจสอบได้ และช่วยให้เรื่องนี้ไม่ค้างอยู่ระหว่างฝ่ายไอทีกับผู้รับจ้างดูแลระบบ
ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน
สถานะการโจมตีมีขอบเขตเวลา HPE ระบุว่า ณ วันออกประกาศยังไม่ทราบว่ามีการพูดถึงช่องโหว่เหล่านี้ต่อสาธารณะหรือมีโค้ดโจมตีเผยแพร่แล้ว ส่วน BleepingComputer รายงานเพิ่มว่ายังไม่พบหลักฐานการนำไปโจมตีจริงตามข้อมูลของบริษัท (HPE, BleepingComputer) ข้อความนี้ไม่ใช่การรับรองสถานะตลอดวันที่ 24 ตุลาคม และไม่ใช่หลักฐานว่าเครื่องใดเครื่องหนึ่งไม่เคยถูกบุกรุก
วันที่ต้องแยกประกาศกับวันที่ข่าวลง HPE ลงวันที่ 22 ตุลาคม 2026 ขณะที่บทความ BleepingComputer ลงวันที่ 23 ตุลาคมและใช้คำว่าแก้ไข “วันนี้” ในเนื้อหา ส่วนข้อมูลกำกับแหล่งข่าวแคนาดาระบุวันที่ 23 ตุลาคม แต่เนื้อประกาศ AV26-1079 ระบุวันที่ 22 ตุลาคม บทความนี้จึงใช้วันที่ 22 ตุลาคมเป็นวันออกประกาศตามเอกสาร HPE โดยไม่ตีความคำว่า “วันนี้” เป็นวันเดียวกันทั้งหมด (HPE, BleepingComputer, Canadian Centre for Cyber Security)
รหัสหนึ่งรายการมีรายงานว่าข้อมูลไม่ตรงกัน Safeguard รายงานเพียงแหล่งเดียวในชุดข้อมูลนี้ว่า ณ วันที่ 23 ตุลาคม CVE-2026-79845 ในฐานข้อมูลสาธารณะบางแห่งชี้ไปยังผลิตภัณฑ์คนละตัว ขณะที่ข้อความ HPE ที่ได้รับระบุรหัสนี้เป็นช่องโหว่ของ AOS-10 คะแนน 10.0 เราจึงยังยืนยันปัญหาในฐานข้อมูลนั้นจากแหล่งอื่นไม่ได้ และควรใช้ประกาศ HPE ประกอบการตรวจรุ่น แทนการตัดสินจากผลค้นหารหัสเพียงอย่างเดียว (Safeguard, HPE)
นอกจากนี้ Safeguard รายงานเพียงแหล่งเดียวในชุดนี้ว่า CVE-2026-79881 มีคะแนนต่างกันระหว่างเอกสารบางรูปแบบ ได้แก่ 8.5 ในรายละเอียดข้อความและระเบียน CVE, 8.3 ในตารางสรุป และ 9.6 ในเอกสารแบบเครื่องอ่านได้ เราไม่มีรายละเอียดรายการนี้จากแหล่งอื่นในข้อความที่ให้มาเพื่อชี้ขาด แต่ความต่างดังกล่าวไม่เปลี่ยนรายการรุ่นแก้ไขที่ HPE แนะนำ (Safeguard, HPE)
ยังไม่มีข้อมูลยืนยันจำนวนองค์กรไทยที่ได้รับผลกระทบ และไม่มีรายละเอียดเงื่อนไขทั้งหมดที่ทำให้ช่องโหว่บางรายการใช้ได้กับการตั้งค่าใดบ้าง ข้อเสนอของผมคือให้บันทึกสิ่งที่ตรวจพบจริงกับสิ่งที่ยังรอผู้ผลิตตอบแยกกัน เพื่อไม่ให้ความไม่ชัดกลายเป็นข้ออ้างเลื่อนงานแก้ไขที่มีรุ่นรองรับแล้ว
แล้วเราควรทำอะไร
ผู้ดูแลไอทีและเครือข่าย
- ทำรายการอุปกรณ์ รุ่นซอฟต์แวร์ และผู้รับผิดชอบให้ครบทั้งตัวควบคุม เกตเวย์ และจุดกระจายสัญญาณ อย่าข้ามเกตเวย์ที่จัดการผ่าน HPE Networking Central เพราะอยู่ในขอบเขตที่ผู้ผลิตระบุด้วย (HPE)
- เทียบกับตารางรุ่นแก้ไข แล้วกำหนดช่วงอัปเกรดให้แต่ละกลุ่ม HPE แนะนำให้อัปเกรดเป็นรุ่นที่ระบุหรือใหม่กว่าในสายที่เหมาะสม ส่วนเครื่องที่ใช้รุ่นสิ้นสุดการสนับสนุนควรมีแผนย้ายไปซอฟต์แวร์ที่ยังรองรับ (HPE)
- ระหว่างรอ ให้จำกัดช่องทางจัดการทั้งแบบหน้าเว็บและแบบพิมพ์คำสั่งไว้ในส่วนเครือข่ายเฉพาะ หรือใช้กฎไฟร์วอลล์ ซึ่งเป็นกฎควบคุมการเชื่อมต่อ พร้อมบันทึกกิจกรรมผู้ใช้และการใช้ทรัพยากรตามคำแนะนำ HPE วิธีนี้เป็นการลดความเสี่ยงระหว่างดำเนินงาน ไม่ควรใช้ปิดงานแทนการอัปเกรด (HPE)
- หลังทำเสร็จ ผมแนะนำให้ตรวจรุ่นที่ทำงานจริง ทดสอบบริการที่ผู้ใช้ต้องพึ่ง และเก็บผลไว้ หากพบการเปลี่ยนค่าหรือกิจกรรมผู้ดูแลที่อธิบายไม่ได้ ให้ตรวจสอบต่อในฐานะเหตุผิดปกติ โดยไม่ด่วนสรุปว่าต้องเกิดจากช่องโหว่ชุดนี้
ผู้จัดการ เจ้าของกิจการ และคนจัดซื้อบริการไอที
- ส่งชื่อประกาศ HPESBNW05162 ให้ผู้ขายหรือผู้ดูแล พร้อมขอรายการเครื่องที่เกี่ยวข้อง รุ่นปัจจุบัน และแผนแก้ไข คำตอบควรระบุได้ว่าแต่ละเครื่องอยู่แถวไหนของตารางผู้ผลิต (HPE)
- ตกลงวันทำงาน ช่วงที่อาจกระทบผู้ใช้ และคนอนุมัติการกลับมาให้บริการ ผมแนะนำให้มีรายการตรวจรับที่อ่านรู้เรื่องสำหรับคนที่ไม่ได้ดูแลเครือข่ายด้วย
- ขอหลักฐานหลังงานเสร็จเป็นรุ่นซอฟต์แวร์และผลตรวจบริการ หากยังทำไม่ได้ ให้ระบุเครื่องที่ค้าง เหตุผล และมาตรการชั่วคราว แทนการรวมทุกเครื่องไว้ในสถานะเดียว
ผู้ให้บริการดูแลไอทีภายนอก หรือ MSP
- แยกรายการอุปกรณ์ตามลูกค้าและสถานะสนับสนุน ระบุว่ารายใดต้องอัปเดตในสายเดิม และรายใดต้องหารือเรื่องย้ายไปสายที่รองรับ โดยยึดขอบเขตและคำแนะนำของผู้ผลิต (HPE)
- ตรวจสิทธิ์เข้าถึงช่องทางจัดการของแต่ละลูกค้า พร้อมเก็บบันทึกกิจกรรมตามคำแนะนำ HPE ผมแนะนำให้รายงานทั้งส่วนที่จำกัดการเข้าถึงแล้วและส่วนที่ยังรออัปเกรด เพื่อให้ลูกค้าเห็นงานคงค้างชัดเจน (HPE)
- ปิดงานด้วยข้อมูลรายเครื่องและสิ่งที่ยังต้องติดตาม โดยเฉพาะเครื่องรุ่นเก่าหรือข้อมูลช่องโหว่ที่ฐานข้อมูลให้ผลไม่ตรงกัน การส่งต่อหลักฐานจะช่วยให้ผู้ดูแลคนถัดไปทำงานต่อได้
ผู้ใช้ Wi-Fi ทั่วไป
- ส่งข่าวให้ฝ่ายไอทีหรือผู้ดูแลสถานที่ หากทราบว่าใช้ Aruba กลุ่มที่ประกาศระบุ ให้ผู้มีหน้าที่ตรวจรุ่นจริงเป็นคนประเมินขอบเขต (HPE)
- ติดตามประกาศช่วงปรับปรุงระบบจากหน่วยงานของตัวเอง และเตรียมงานที่ต้องใช้อินเทอร์เน็ตตามคำแนะนำของผู้ดูแล ไม่จำเป็นต้องลองเข้าหน้าจัดการอุปกรณ์เพื่อพิสูจน์ข่าวด้วยตนเอง
ผมมองว่า…
ผมมองว่า นี่เป็นความเห็นของผม: งานเร่งด่วนไม่ใช่การท่องรหัสช่องโหว่ แต่คือการรู้ว่าเครื่องไหนอยู่กับใครและแก้เมื่อไร คะแนนเต็มช่วยให้เรื่องนี้ได้รับความสนใจ แต่ข้อมูลรุ่นจริง ผู้รับผิดชอบ และช่วงเวลาลงมือคือสิ่งที่ทำให้ความเสี่ยงได้รับการจัดการ
ผมยังมองว่าการรายงานว่าไม่ทราบว่ามีโค้ดโจมตีสาธารณะ ณ วันประกาศ เป็นข้อมูลประกอบการตัดสินใจที่ดี แต่ไม่ควรทำให้เลื่อนการอัปเกรดที่ผู้ผลิตขอให้เร่งทำ (HPE) สำหรับทีมเล็ก การเริ่มจากบัญชีอุปกรณ์ที่เชื่อถือได้และการนัดหมายกับผู้ดูแล น่าจะให้ผลชัดกว่าการอ่านข่าวจบแล้วรอข่าวการโจมตีรอบถัดไป
ปิดท้าย: สิ่งที่ต้องจับตา
สิ่งที่ควรติดตามต่อคือการปรับปรุงประกาศ HPE สถานะข้อมูลรหัสที่ Safeguard รายงานว่ายังไม่ตรงกันเพียงแหล่งเดียวในชุดนี้ และข้อมูลใหม่เกี่ยวกับการโจมตีจริง โดยสถานะที่ผู้ผลิตให้ไว้ยังอ้างอิงวันออกประกาศ 22 ตุลาคม 2026 เท่านั้น (HPE, Safeguard)
สำหรับองค์กรของคุณ ผมแนะนำให้จบการติดตามรอบแรกด้วยคำตอบที่ตรวจสอบได้: มีเครื่องอะไรบ้าง ใช้รุ่นไหน ใครเป็นคนแก้ และยังเหลือเครื่องใดรออยู่ หากทำได้ครบ ข่าวช่องโหว่ครั้งนี้ก็จะกลายเป็นงานที่มีเจ้าของและมีหลักฐานปิดงานครับ
Recap
- ตรวจว่าองค์กรใช้อุปกรณ์ Aruba AOS-8 หรือ AOS-10 ในขอบเขตประกาศหรือไม่
- ทำรายการรุ่นซอฟต์แวร์จริง รวมอุปกรณ์ที่จัดการผ่านระบบส่วนกลาง
- เทียบรุ่นกับตารางแก้ไขของ HPE ตามสายซอฟต์แวร์ให้ถูกต้อง
- กำหนดผู้รับผิดชอบและช่วงเวลาอัปเกรดที่แจ้งผู้ใช้แล้ว
- จำกัดการเข้าถึงช่องทางจัดการและเก็บบันทึกกิจกรรมระหว่างรอ
- แยกรุ่นที่สิ้นสุดการบำรุงรักษาหรือการสนับสนุนเพื่อวางแผนต่อ
- ตรวจรุ่นหลังอัปเกรด ทดสอบบริการ และเก็บหลักฐานรายเครื่อง
- ติดตามประกาศใหม่ โดยไม่ตีความสถานะวันเผยแพร่ว่าเป็นคำรับรองความปลอดภัยตลอดไป