לפי הודעת Okta מ־5 בנובמבר 2026, מפתחות גישה אינם דורשים עוד תוסף MFA. החברה מתארת ברירת מחדל עמידה לפישינג במדיניות כניסה חדשה ליישומים, בלי לפרט פריסה או טבלת רישוי.
זהו שינוי בדרישת הרישוי שפורסמה: הכרזת מפתחות הגישה מספטמבר 2025 דרשה רישוי MFA או AMFA. התמיכה במפתחות גישה עצמם כבר הייתה קיימת. לצוות שדחה אימוץ בגלל רישוי, זו סיבה לבדוק מחדש זכאות, ולא בסיס לביטול מנוי אבטחה קיים.
בדקו איזו מדיניות חלה בפועל
יש פער בתיעוד שכדאי לבדוק. מדריך מדיניות היישומים הנוכחי עדיין מתאר כלל ברירת מחדל במדיניות חדשה שמקבל כל שני סוגי גורמי אימות. בנפרד הוא מציין ש־Passkey ו־Okta FastPass עומדים בדרישת גורם החזקה עמיד לפישינג. התייחסו לניסוח בבלוג כהכרזה, ולא כאימות של ההגדרה בסביבה שלכם.
ברירת מחדל אחרת קדמה לחדשות האלה: גרסה 2026.41.0, שנפרסה ב־12 באוקטובר, הפכה את מאמת Passkey לזמין כברירת מחדל בארגונים חדשים. זמינות של מאמת והדרישה להשתמש בו בכניסה ליישום הן שאלות שונות.
בדיקה מצומצמת לפני הרחבת הפריסה
הצעד הבא שאנו מציעים הוא ניסוי מתועד עם אחראי והחלטה לגבי חזרה לאחור, במקום שינוי כלל־ארגוני על סמך כותרת:
- זכאות: ודאו אילו בקרות כלולות בהסכם. אל תניחו שכל יכולת אבטחה כלולה.
- גישה ליישום: תעדו את המדיניות, הכלל המתאים והחריגים עבור יישום מייצג אחד. השוו את הדרישה המתוכננת לכניסה בפועל של משתמש בדיקה.
- שחזור גישה: תרגלו מקרה של מכשיר שאבד ומשתמש שטרם נרשם. הגדירו מסלול שחזור נתמך לפני ביטול שיטה קיימת.
- ראיות: שמרו את תוצאת הניסוי, הפערים שנותרו וזהות המאשר את ההרחבה. כניסה מוצלחת לבדה אינה מוכיחה שכל מסלולי הגישה עומדים בדרישה הרצויה.
לא בדקנו סביבת לקוח. ודאו עם Okta את הזכאות ואת המדיניות בפועל; אל תניחו שמדיניות קיימת השתנתה אוטומטית.