Multi-factor authentication (MFA) was meant to end the stolen-password problem. It made attacks harder, but the most common second factors, a six-digit code from an app or a text message, share a weakness with the password itself: a person can be persuaded to type them into the wrong page.
This guide explains how codes get phished, what “phishing-resistant” actually means, and what to look for when you replace codes on employee laptops and work apps. It ends with where CyberCyko Workforce fits today and where its scope stops.
How a one-time code gets phished
A modern phishing kit does not simply collect a password and stop. It sits between the employee and the real sign-in page and passes each step through as it happens. The employee sees a page that looks right, types their password, then types the code from their phone. The kit forwards both to the real service within seconds, completes the sign-in and keeps the session that results. This is usually called an adversary-in-the-middle attack.
The code did exactly what it was designed to do. It proved that someone had the phone at that moment. What it could not prove was where the code was being typed. A one-time code is a secret the employee reads and repeats, and anything a person can read and repeat, a convincing page can ask for.
Codes sent by text message carry extra risks. A phone number can be moved to an attacker’s SIM card through a SIM swap, and messages can be intercepted or forwarded. Codes from an authenticator app avoid those problems, but not the relay described above.
What phishing-resistant actually means
A sign-in method is phishing-resistant when there is nothing the employee could hand over that would let an attacker sign in somewhere else. In practice that comes down to three properties.
No shared secret to type. If the employee never types a password or a code, a fake page has nothing to collect, however convincing it looks.
A private key that stays on the device. The credential is a cryptographic key generated on the employee’s own hardware. The service keeps only the matching public key, which cannot be used to sign in. Where the device has a security chip, the private key is kept inside it and cannot be exported.
A check tied to a fresh challenge. The device signs a new challenge for each sign-in, so a response captured once is of no use again. Standards such as FIDO2 and WebAuthn are built on these ideas, and government security guidance commonly points to them, along with certificate-based sign-in, as the phishing-resistant options.
Why a push approval on its own is not enough
Push approvals, where the phone simply asks “Is this you?”, remove the code but can bring the human weak point back in another form. An attacker who already has a password can trigger request after request until a tired or distracted employee taps Approve. Our guide to MFA fatigue attacks covers this in detail.
The answer is not to abandon phone approval. It is to make the approval part of a flow with no password to steal in the first place, to ask for a live fingerprint or face rather than a bare tap, and to tie access to a device the organisation has enrolled.
How CyberCyko Workforce takes the code out
In CyberCyko Workforce the employee wakes their laptop or opens a work app, their enrolled phone shows the request, and they confirm with a fingerprint or face. There is no password and no one-time code anywhere in that flow, so there is nothing to type into a page.
The key that signs them in is generated on the enrolled phone and held inside its security chip. CyberCyko keeps your user list (name, work email) and public keys, not passwords or any other secret that could sign someone in. Work apps that support standard single sign-on accept sign-in from CyberCyko, so the same phone approval is used for apps such as Microsoft 365, Google Workspace, Slack and GitHub, and apps you mark as sensitive can ask for a second approval.
You can follow the whole laptop flow, from the phone approval to the open desktop, on the passwordless laptop sign-in page.
Questions to ask of any phishing-resistant option
Whatever you evaluate, a handful of questions separate real phishing resistance from a code with a new name.
Is anything typed? If there is any point in the flow where the employee types a password or a code, that is the part an attacker will target.
Where is the private key created, and can it be exported? Ask which devices keep it inside a security chip, and what happens on devices that do not have one.
What happens when a phone is lost or replaced? Removing the old phone should stop it approving sign-in straight away, and the new phone should get its own key rather than a copy of the old one.
What is covered today? Ask which laptops, phones and apps work now and which are on a roadmap. Apps that do not support standard single sign-on still need their own sign-in, so list them.
What is logged? You want a record of every grant, removal and admin action, kept in a way that shows any later edit.
Keep the scope clear
Today: Windows laptops are fully managed, and passwordless sign-in works on Windows and at the Mac lock screen. Management for Mac, Ubuntu, Android and iOS is in development. The iPhone and Android apps approve employee sign-in. They do not give IT control of the phone.
Phishing-resistant sign-in is one control, not a whole security programme. Keep teaching people to report suspicious messages, keep laptops encrypted and up to date, and review who has access to what. Taking the code out of the flow removes one of the things attackers most often steal, so the rest of the programme has less to catch.
See how it works in CyberCyko Workforce
See passwordless laptop sign-in Related