Passkeys by default: Είναι όμως και το account recovery σας phishing-resistant;

Η Microsoft αλλάζει το authentication στο Entra ID. Το πραγματικό Identity risk όμως μπορεί να βρίσκεται στη διαδικασία που χρησιμοποιείτε όταν ένας χρήστης χάσει την πρόσβασή του.

Από την 1η Σεπτεμβρίου 2026, η Microsoft αλλάζει σημαντικά την authentication experience στο Microsoft Entra ID.

Οι χρήστες που παραμένουν enabled για SMS ή voice authentication θα γίνουν automatically enabled για passkeys και θα ενταχθούν σε Registration Campaign που θα τους προτρέπει να εγγραφούν για passkey.

Από την 1η Φεβρουαρίου 2027, το Microsoft-provided telecom delivery για SMS και voice authentication αποσύρεται. Οργανισμοί που εξακολουθούν να έχουν τεκμηριωμένη operational ή regulatory ανάγκη για SMS ή voice θα μπορούν να χρησιμοποιήσουν customer-managed telecom provider.

Η κατεύθυνση είναι σωστή.

Τα passkeys βασίζονται σε public-key cryptography και έχουν σχεδιαστεί ώστε να παρέχουν phishing-resistant authentication. Στο Microsoft Entra ID τα Passkeys (FIDO2) είναι διαθέσιμα σε όλες τις editions, συμπεριλαμβανομένου του Microsoft Entra ID Free, χωρίς πρόσθετο licensing requirement για τη συγκεκριμένη authentication method.

Όμως υπάρχει ένα δεύτερο ερώτημα που θεωρώ σημαντικότερο από το ίδιο το rollout:

Τι συμβαίνει όταν ο νόμιμος χρήστης δεν μπορεί πλέον να χρησιμοποιήσει το passkey του;

Γιατί το πραγματικό assurance ενός authentication architecture δεν καθορίζεται μόνο από τον ισχυρότερο authenticator.

Καθορίζεται και από τη διαδικασία που μπορεί να τον αντικαταστήσει.

Phishing-resistant authentication. Phishable recovery;

Το Microsoft Digital Defense Report 2025 δίνει ένα ενδιαφέρον μέτρο του προβλήματος.

Η modern Multi-Factor Authentication (MFA) εξακολουθεί να μειώνει τον κίνδυνο identity compromise περισσότερο από 99%.

Στο dataset της Microsoft Defender XDR και του Microsoft Entra ID Protection για την περίοδο Απριλίου–Ιουνίου 2025:

• περισσότερο από 97% των identity attacks ήταν password spray ή brute-force attacks,

• token theft by malware αντιπροσώπευε 2,4042%,

• Adversary-in-the-Middle (AiTM) attacks 0,2375%,

• direct attacks on MFA μόλις 0,0033%.

Δεν θα πρέπει να διαβάσουμε αυτά τα δεδομένα ως απόδειξη ότι οι attackers «σταμάτησαν να επιτίθενται στο MFA».

Η ίδια έκθεση όμως καταγράφει μια άλλη σημαντική τάση.

Ransomware operators χρησιμοποιούν όλο και περισσότερο social engineering για να αποκτήσουν ή να κάνουν reset credentials, ιδιαίτερα μέσω vishing και tech-support scams.

Η Microsoft αναφέρει επίσης helpdesk-themed social engineering ως πραγματικό attack pattern.

Αυτό μας οδηγεί σε ένα σημαντικό architectural conclusion:

Phishing-resistant authentication δεν συνεπάγεται phishing-resistant account recovery.

Το account recovery είναι authentication control

Όταν ένας εργαζόμενος χάσει το κινητό του, αντικαταστήσει συσκευή ή δεν μπορεί πλέον να χρησιμοποιήσει τον authenticator του, κάποια διαδικασία πρέπει να του επιστρέψει την πρόσβαση.

Ανάλογα με το περιβάλλον, αυτή μπορεί να περιλαμβάνει:

• Self-Service Password Reset (SSPR),

• password reset από helpdesk,

• αλλαγή ή διαγραφή authentication methods,

• απαίτηση re-registration,

• έκδοση Temporary Access Pass (TAP),

• lost-device ή replacement-device procedure,

• administrator-assisted recovery,

• intervention από Managed Service Provider (MSP).

Αυτές οι διαδικασίες συχνά αντιμετωπίζονται ως operational helpdesk workflows.

Από security perspective όμως είναι κάτι περισσότερο.

Είναι εναλλακτικές authentication paths.

Αν ένας attacker μπορεί μέσω social engineering να προκαλέσει την εγγραφή ενός νέου authenticator ή την έκδοση Temporary Access Pass, δεν χρειάζεται να παραβιάσει το υπάρχον passkey.

Χρειάζεται να παραβιάσει τη διαδικασία που επιτρέπει την αντικατάστασή του.

Και αυτή η διαδικασία μπορεί να εκτελείται από άνθρωπο.

Approval δεν σημαίνει identity verification

Εδώ εμφανίζεται συχνά ένα control-design error.

Ο manager μπορεί να επιβεβαιώσει ότι ένας εργαζόμενος πράγματι χρειάζεται νέα συσκευή ή recovery.

Αυτό δεν αποδεικνύει από μόνο του ότι ο άνθρωπος που βρίσκεται στο τηλέφωνο ή στο ticket είναι πράγματι αυτός ο εργαζόμενος.

Για high-impact recovery actions χρειάζεται προκαθορισμένη διαδικασία identity verification.

Ανάλογα με το risk level, αυτή μπορεί να περιλαμβάνει:

known communication channel, trusted corporate records, independent verification, out-of-band confirmation και dual control.

Και κυρίως:

η διαδικασία πρέπει να είναι documented, repeatable και auditable.

Όχι να εξαρτάται από το πόσο πειστικός φαίνεται ο caller.

Τι συμβαίνει όταν το helpdesk είναι εξωτερικό;

Το πρόβλημα αποκτά διαφορετική διάσταση όταν password resets, authentication-method changes ή privileged Identity operations εκτελούνται από external IT provider.

Σε αυτή την περίπτωση, μέρος του Identity Security boundary του οργανισμού βρίσκεται πρακτικά σε τρίτο μέρος.

Αυτό έχει ιδιαίτερη σημασία για οργανισμούς που βασίζονται σε external IT providers και Managed Service Providers (MSPs).

Το σωστό security question επομένως δεν είναι μόνο:

«Χρησιμοποιεί MFA ο πάροχός μας;»

Είναι:

«Με ποια διαδικασία αποδεικνύει την ταυτότητα ενός δικού μας εργαζομένου πριν αλλάξει authentication method ή του επιστρέψει πρόσβαση;»

Και μετά ακολουθούν ακόμη πιο δύσκολες ερωτήσεις:

Ποιος μπορεί να εγκρίνει το recovery;

Μπορεί ένας helpdesk operator μόνος του να εκδώσει Temporary Access Pass;

Υπάρχει διαφορετική διαδικασία για privileged accounts;

Καταγράφεται ποιος πραγματοποίησε την αλλαγή;

Υπάρχει alert μετά από high-risk recovery action;

Γίνεται correlation με authentication-method registration και επόμενο sign-in;

Αν δεν γνωρίζετε τις απαντήσεις, δεν γνωρίζετε πλήρως το assurance level του authentication environment σας.

Το περιστατικό της Marks & Spencer

Η κυβερνοεπίθεση στη Marks & Spencer το 2025 αποτελεί χρήσιμη υπενθύμιση του συγκεκριμένου risk.

Στις 8 Ιουλίου 2025, ο Chairman της M&S Archie Norman κατέθεσε ενώπιον του UK Parliament ότι το initial entry της επίθεσης έγινε μέσω sophisticated impersonation.

Όπως εξήγησε, οι attackers εμφανίστηκαν ως συγκεκριμένο άτομο και διέθεταν προσωπικές πληροφορίες του.

Επιβεβαίωσε επίσης ότι μέρος του point of entry αφορούσε third party.

Χρειάζεται όμως προσοχή στην ερμηνεία.

Η επίσημη δημόσια κατάθεση δεν επιβεβαιώνει ότι συγκεκριμένο external helpdesk πραγματοποίησε password reset. Δεν υπάρχει λόγος να αποδώσουμε στο περιστατικό περισσότερη τεχνική λεπτομέρεια από αυτή που έχει τεκμηριωθεί.

Το lesson είναι ήδη αρκετά ισχυρό:

Identity impersonation και third-party trust αποτελούν πραγματικό attack surface.

Δεν απαιτείται exploit αν μια κρίσιμη operational process μπορεί να χειραγωγηθεί.

Από Identity Security σε NIS2 Governance

Για τις βασικές και σημαντικές οντότητες που εμπίπτουν στο πεδίο εφαρμογής του Ν. 5160/2024, το θέμα δεν περιορίζεται στο technical configuration.

Ο Ν. 5160/2024, με τον οποίο ενσωματώθηκε στην ελληνική νομοθεσία η Network and Information Systems Directive 2 (NIS2), απαιτεί από τα όργανα διοίκησης να εγκρίνουν τα cybersecurity risk-management measures και να επιβλέπουν την εφαρμογή τους.

Τα απαιτούμενα measures περιλαμβάνουν, μεταξύ άλλων, access-control policies και χρήση Multi-Factor Authentication (MFA), όπου απαιτείται.

Η Κοινή Υπουργική Απόφαση 1689/2025, μέσω του Εθνικού Πλαισίου Απαιτήσεων Κυβερνοασφάλειας, εξειδικεύει περαιτέρω το framework για τις βασικές και σημαντικές οντότητες.

Το σημαντικό σημείο εδώ είναι το governance principle:

Η ανάθεση μιας λειτουργίας σε external provider δεν μεταφέρει αυτομάτως και το risk ownership εκτός του οργανισμού.

Εάν ένας third party μπορεί να επηρεάσει authentication, privileged access ή account recovery, η διαδικασία αυτή πρέπει να ενταχθεί στο access-control και supplier-risk framework του οργανισμού.

Το recovery process επομένως δεν είναι απλώς θέμα του helpdesk.

Είναι Identity Governance θέμα.

Και, για τους οργανισμούς που βρίσκονται εντός του NIS2 scope, μπορεί να αποτελεί μέρος του ευρύτερου cybersecurity risk-management και compliance framework. Τι θα έλεγχα πριν θεωρήσω το passkey rollout ολοκληρωμένο

1. Χαρτογράφηση όλων των recovery paths

Όχι μόνο των authentication methods.

Καταγράψτε:

• password recovery,

• authentication-method replacement,

• Temporary Access Pass issuance,

• lost-device procedures,

• administrator-assisted recovery,

• external provider workflows,

• privileged identity recovery.

Για κάθε path πρέπει να είναι γνωστό ποιος το ενεργοποιεί, ποιος το εγκρίνει και ποια controls εφαρμόζονται.

2. Identity proofing πριν από high-risk recovery

Το «κάνουμε μερικές ερωτήσεις στον χρήστη» δεν αποτελεί επαρκές security design.

Η διαδικασία πρέπει να καθορίζει με σαφήνεια πώς επαληθεύεται η ταυτότητα του claimant και ποια channels θεωρούνται trusted.

3. Διαφορετικό assurance για διαφορετικό impact

Δεν έχουν όλες οι recovery operations τον ίδιο κίνδυνο.

Ένα password reset δεν πρέπει αυτομάτως να αντιμετωπίζεται με τον ίδιο τρόπο όπως:

• έκδοση Temporary Access Pass,

• αντικατάσταση phishing-resistant authenticator,

• recovery administrator account,

• recovery privileged identity.

Όσο αυξάνεται το potential impact, πρέπει να αυξάνεται και το assurance της recovery διαδικασίας.

4. Έλεγχος των privileged recovery roles

Ποιοι έχουν δικαιώματα να αλλάξουν authentication methods άλλων χρηστών;

Ποιοι μπορούν να επηρεάσουν privileged accounts;

Είναι οι ρόλοι permanent ή χρησιμοποιείται Privileged Identity Management (PIM);

Υπάρχει separation of duties;

Υπάρχει monitoring;

Το recovery architecture δεν μπορεί να αξιολογηθεί ανεξάρτητα από το privileged-access model.

5. Emergency access ως ξεχωριστό control

Τα emergency access — ή break-glass — accounts δεν είναι «ένα ακόμα admin account».

Η Microsoft συνιστά τουλάχιστον δύο cloud-only emergency access accounts, με ισχυρό phishing-resistant authentication, ανεξάρτητες dependencies, monitoring κάθε χρήσης και τακτικό validation.

Το emergency access πρέπει να είναι σχεδιασμένο ώστε να λειτουργεί όταν τα normal controls αποτύχουν — χωρίς όμως να μετατρέπεται σε permanent bypass.

6. Monitoring του sequence, όχι μόνο του event

Ένα μεμονωμένο password reset μπορεί να είναι απολύτως νόμιμο.

Το ίδιο και μια νέα authentication-method registration.

Το ίδιο και ένα sign-in από νέα συσκευή.

Η αλληλουχία όμως:

recovery action → new authentication method → unusual sign-in → privilege change

έχει διαφορετική σημασία.

Για αυτό το Identity monitoring πρέπει να εξετάζει event correlation και behavioral sequence, όχι μόνο isolated alerts.

Η 1η Σεπτεμβρίου είναι trigger — όχι ο πραγματικός στόχος

Η αλλαγή της Microsoft είναι μια καλή αφορμή για να κινηθούν οι οργανισμοί προς phishing-resistant authentication.

Δεν θα την αντιμετώπιζα όμως ως απλό migration project από SMS σε passkeys.

Είναι ευκαιρία να ελεγχθεί ολόκληρο το authentication lifecycle:

registration → authentication → replacement → recovery → privileged recovery → emergency access → monitoring.

Τα passkeys λύνουν ένα σημαντικό security problem.

Δεν λύνουν κάθε Identity problem.

Και ένα authentication architecture δεν πρέπει να αξιολογείται από το ισχυρότερο control του.

Πρέπει να αξιολογείται από την ευκολότερη διαδρομή που επιτρέπει να παρακαμφθεί ή να αντικατασταθεί αυτό το control.

Η ερώτηση που θα έθετα σήμερα

Όχι:

«Έχουμε ενεργοποιήσει passkeys;»

Αλλά:

«Αν ένας attacker δεν μπορεί να κλέψει το authenticator μας, μπορεί να πείσει κάποιον να του εκδώσει καινούργιο;»

Αν η απάντηση δεν είναι ξεκάθαρη και τεκμηριωμένη, εκεί θα ξεκινούσα τον έλεγχο.

Identity Recovery & Passkey Readiness

Στη Nimbus Cyber αντιμετωπίζουμε authentication και recovery ως ένα ενιαίο Identity control system.

Το working model του Identity Recovery & Passkey Readiness Assessment εξετάζει ενδεικτικά:

• passkey readiness και authentication-method architecture,

• account-recovery paths,

• Temporary Access Pass governance,

• privileged recovery,

• emergency access accounts,

• helpdesk και third-party procedures,

• logging, monitoring και detection,

• alignment με Identity Governance και, όπου εφαρμόζεται, NIS2 requirements.

Ο στόχος δεν είναι απλώς να ενεργοποιηθεί ένα ισχυρότερο authentication method.

Είναι να διασφαλιστεί ότι ο δρόμος επιστροφής στην πρόσβαση δεν είναι ασθενέστερος από την ίδια την είσοδο.