Why SMS and push codes fall to phishing
An SMS code and a push approval share one weakness: an attacker can trick the user into handing over either of them.
All it takes is a fake sign-in page where the user types a password and a code. The attacker immediately replays both on the real site. Or the user, unaware of the trick, enters the SMS code or approves the push prompt, which opens the account to the attacker on the real site.
SMS codes can also be intercepted by taking over the phone number (SIM swap).
FIDO2, passkeys and Okta FastPass
FIDO2 and WebAuthn are standards in which a cryptographic key is bound to the domain of the real site. On a fake domain the device will not produce a response the attacker could use on the real site, so there is nothing to trick out of the user.
- FIDO2 security keys: a physical key (USB or NFC) that works across many devices and suits privileged accounts well.
- Passkeys: WebAuthn-based credentials stored on the user's device and sometimes synced across their devices, unlocked with biometrics or the device PIN.
- Okta FastPass: a factor in the Okta Verify app in which the device verifies the sign-in. It counts as phishing-resistant only when policy requires phishing-resistant authentication. Okta can also take the device's posture into account in policy.
The choice depends on your users' devices: Okta FastPass where the device can run Okta Verify, FIDO2 keys for privileged accounts, and for your product's customers, passkeys in Auth0, which we cover in the guide CIAM with Auth0 in practice.
NIS2 and multi-factor authentication
Under Article 21(2)(j) of the NIS2 Directive, risk-management measures include, where appropriate, the use of multi-factor authentication or continuous authentication solutions. In Poland these obligations come from the amended National Cybersecurity System Act (KSC).
The directive does not name a specific MFA method, so the choice of factors follows from your organization's risk analysis. Phishing-resistant factors are one way to meet that in practice. Confirm which measures your organization must apply with your compliance team or a lawyer. We cover NIS2 in Poland in more depth on the NIS2 / KSC page.
A staged rollout
We plan the rollout group by group, to limit the risk to users' daily work. We configure policies in Okta, require phishing-resistant factors in each group and aim to retire weaker MFA factors.
Admins
We start with admin accounts, because taking one over gives an attacker the most room to maneuver. For this group, phishing-resistant MFA factors are required from day one.
Higher-risk groups
Next we cover groups with access to financial or HR data or to source code, and people who are targeted often, such as executives and the finance team.
All users
Last, we extend the policy to everyone else, once the help desk and the first groups are used to the new way of signing in.
Account recovery and exceptions
The weakest link is often account recovery: if an account can be recovered with a quick call to the help desk, an attacker can impersonate the user and ask for a reset. That is why we define how the help desk verifies identity and when it needs confirmation from a second person.
A user lost their key or phone.
−The help desk resets the factor after a short phone call.
+We register at least two factors per account and verify identity through a set procedure, for example with a manager's involvement.
Some users have no device that runs Okta Verify.
−SMS stays on as a permanent exception for them, with no end date.
+We give them FIDO2 keys, and we record every exception with an owner and a review date.
SMS stays in the policy as a fallback sign-in method.
−The attacker picks the weakest available path, which is exactly that SMS fallback.
+We require phishing-resistant factors and aim to retire weaker MFA factors.
Exceptions and policies need reviews after the rollout too, and we describe the scope of that care on the Okta managed services page.
CEO
Jan Czajkowski is the CEO and co-founder of Zelto, an official Okta partner that helps organizations design, deploy and run identity and access management.
More from Jan →Let's talk about MFA in your company
Tell us about your devices and user groups, and we will propose a rollout order. If you prefer email, write to hello@zelto.id.