הנחיות ה-FDA החדשות לאבטחת סייבר במכשור רפואי - פברואר 2026

בתחילת פברואר 2026 פרסם ה-FDA הנחיה מעודכנת ומשמעותית בתחום אבטחת סייבר במכשור רפואי:

Cybersecurity in Medical Devices: Quality Management System (QMS) Considerations and Content of Premarket Submissions.

ההנחיה הזאת מחליפה את גרסת 2025 ומחדדת מסר שה-FDA מדגיש כבר כמה שנים, אך כעת בצורה ברורה, עמוקה ומעשית יותר:
אבטחת סייבר היא חלק בלתי נפרד מבטיחות המכשיר וממערכת האיכות, ולא נושא טכני נפרד שאפשר לדחות לסוף הפיתוח.

המסמך המלא פורסם ב-3 בפברואר 2026 וכולל דרישות וציפיות ברורות מיצרני מכשור רפואי, החל מסטארטאפים בתחילת הדרך ועד חברות גלובליות עם מוצרים מחוברים מורכבים.

למה ההנחיה הזאת כל כך חשובה?

בשנים האחרונות ה-FDA ראה עלייה חדה באירועי סייבר שפגעו ישירות במערכות רפואיות:
השבתת רשתות בתי חולים, פגיעה בזמינות מכשירים, עיכובים באבחון ובטיפול, ולעיתים גם סיכון ממשי למטופלים.

כתוצאה מכך, ה-FDA מבהיר כעת באופן חד-משמעי:
מכשור רפואי שאינו מוגן כראוי מפני איומי סייבר עלול להיחשב כמכשור שאינו בטוח או אפקטיבי.

העיקרון המרכזי: סייבר = בטיחות + איכות

אחת האמירות החזקות ביותר בהנחיה החדשה היא:
אבטחת סייבר היא חלק מה-Quality Management System Regulation (QMSR), שמיישר קו עם ISO 13485.

כלומר:

• סייבר הוא לא "נספח רגולטורי"

• לא מסמך IT צדדי

• ולא משהו שמוסיפים רגע לפני הגשת (k)510 או PMA

אלא חלק מובנה מ:

• ניהול סיכונים

• Design & Development

• וליווי המוצר לאורך כל מחזור החיים (Total Product Lifecycle)

אימוץ Secure Product Development Framework (SPDF)

ה-FDA ממליץ במפורש לאמץ Secure Product Development Framework – SPDF.

מה זה אומר בפועל?
מדובר בגישה שיטתית לפיתוח מוצר, שבה אבטחת סייבר משולבת:

• כבר בשלב האפיון

• לאורך התכנון והפיתוח

• בבדיקות

• וגם לאחר ההשקה - בעדכונים, תיקונים ותמיכה בשוק

ניהול סיכוני סייבר: לא רק Safety Risk

ה-FDA מדגיש הבחנה חשובה:

• Safety Risk Management לפי ISO 14971

• Security Risk Management - תהליך נפרד אך מחובר

ניהול סיכוני סייבר מתמקד בשאלות כמו:

• עד כמה קל לנצל חולשה?

• מה ההשפעה של פריצה על המטופל, המשתמש או המערכת?

• האם קיימות פגיעויות ידועות ברכיבי צד ג'?

נקודה קריטית:

הערכת סיכוני סייבר היא לא הסתברותית קלאסית.
היא מבוססת על exploitability, כלומר עד כמה תוקף יכול לנצל את החולשה, במיוחד לאורך זמן.

Threat Modeling - דרישה מרכזית

לראשונה בצורה כל כך ברורה, ה-FDA מצפה לראות Threat Modeling מתועד בהגשות קדם-שיווקיות.

ה-Threat Model צריך:

• לכסות את כל "מערכת" המכשור, לא רק את המכשיר עצמו

• לכלול רשתות, ענן, עדכונים, שרשרת אספקה

• להתייחס גם לשימוש לרעה צפוי (reasonably foreseeable misuse)

דוגמה:

מכשיר שמחובר לרשת בית חולים - ה-FDA מצפה שתניחו שהרשת "עוינת",
ותראו איך המכשיר שומר על עצמו גם בתרחיש כזה.

מה ה-FDA מצפה לראות בהגשות (510k, PMA ועוד)

ההנחיה מפרטת בצורה מדויקת אילו מסמכי סייבר נדרשים, ביניהם:

• דו"ח ניהול סיכוני סייבר

• Threat Model

• ארכיטקטורת אבטחה

• בדיקות סייבר (כולל בדיקות חדירה)

• SBOM – Software Bill of Materials

והכול צריך להיות עקבי, ניתן למעקב (traceable) ומחובר למערכת האיכות.

Security Objectives - ציפיות ברורות

ה-FDA מגדיר יעדי אבטחה שמצופה להוכיח בהגשה:

• Authenticity ו-Integrity

• Authorization

• Confidentiality

• Availability

• יכולת עדכון ותיקון מאובטחת ובזמן

אלה לא דרישות "nice to have", אלא ציפיות רגולטוריות.

על מי זה חל?

ההנחיה חלה על:

• כל מכשיר עם תוכנה או קושחה

• מכשירים מחוברים, כולל ענן ואפליקציות

• "Cyber Devices" לפי סעיף 524B ל-FD&C Act

מה המשמעות הפרקטית ליצרנים?

לחברות סטארטאפ:

• תחשבו סייבר כבר בשלב הארכיטקטורה

• אל תבנו מערכת איכות בלי תהליך סייבר מובנה

• אל תניחו שאפשר "להשלים מסמכים" רגע לפני ההגשה

לחברות מבוססות:

• עדכנו נהלים ותהליכים בהתאם ל-QMSR

• וודאו ש-SPDF באמת מיושם ולא רק מתואר

• חזקו את החיבור בין פיתוח, רגולציה, איכות ו-IT

לסיכום - מסר ברור מה-FDA

ההנחיה החדשה לא משאירה מקום לפרשנות:
אבטחת סייבר היא תנאי לבטיחות ולרגולציה.

מי שישלב סייבר כחלק טבעי ממערכת האיכות ומהפיתוח -
יקל על עצמו בהגשות, יקטין סיכונים בשוק, ויחזק אמון מול רגולטורים ולקוחות.

מי שימשיך להתייחס לסייבר כאל "עוד מסמך" -
עלול לשלם על כך בעיכובים, שאלות רגולטוריות, או גרוע מכך - אירועי שטח.