Let’s face it: we all use email, and we all use passwords. Passwords create an inherent vulnerability in the system. The success rate of phishing attacks is skyrocketing, and opportunities for attack have multiplied enormously as life has moved online. All it takes is one compromised password for all other users to fall victim to a data breach.
That’s why, to provide additional security, digital identities rely on verification patches. Multi-factor authentication (MFA) often relies on knowledge factors such as password resets and OTP codes, but these remain vulnerable. As long as credentials can be shared or intercepted, they can be misused.
What is needed is a paradigm shift: moving from knowledge-based credentials to strong possession-factor security that cannot be compromised, along with other verification safeguards such as biometrics.
A new possession factor API now aims to do just that, replacing knowledge-based credentials by using the SIM card to link the possession factor device and authenticate the user, thereby reducing the possibility of identity theft.
Phishing: a human problem
Phishing and other types of social engineering rely on the human factor being the weakest link in a breach. They exploit the convenient credential-based access that the average user has to a platform, tricking those average users into sharing their credentials. And it works: 83% of organizations surveyed reported experiencing a successful email-based phishing attack in 2021.
Even 2FA codes are now targets
It is well known that passwords can be shared and therefore easily spoofed. But a lesser-known fact is that many forms of 2FA—such as OTP or PIN codes added in an effort to reinforce the known weaknesses of passwords—are also susceptible to spoofing.
Worse still, criminals are now specifically targeting these methods: researchers have recently discovered that there are more than 1,200 phishing kits designed to steal 2FA codes.
The answer to identity and access management, therefore, is not to apply more patches that ruin the user experience, as these do not actually keep attackers at bay. Instead, MFA needs a stronger and simpler possession factor, with nothing to type in, meaning there is nothing to spoof.
Purpose-built MFA possession factors include dongles or security tokens. But they are expensive and not something the average user is going to buy. Stronger security for everyone can only work with devices that are widely available, easy to use, easy to integrate, and cost-effective.
The SIM card. It’s inside everyone’s cell phone, and it relies on cryptographic security when connecting to mobile network authentication.
Now, for the first time, a tru.ID API opens up SIM-based mobile network authentication to all businesses and app developers, meaning SIM security can be leveraged as a secure possession factor for MFA.
SIM-based authentication: the new phishing-resistant possession factor
The SIM card has a lot going for it. SIM cards use the same high-security cryptographic microchip technology that is embedded in all credit cards. It is difficult to clone or tamper with, and there is a SIM card in every mobile phone, so every user already has this hardware in their pocket.
The combination of the mobile phone number and the associated SIM card identity (the IMSI) is a difficult combination to forge, as it is a silent authentication check.
The user experience is also superior. Mobile phone networks routinely perform silent checks that a user’s SIM card matches their phone number to allow them to send messages, make calls, and use data, ensuring real-time authentication without the need to log in.
Until recently, companies couldn’t program a mobile network’s authentication infrastructure into an app as easily as any other code. tru.ID makes network authentication accessible to everyone.
Adding the tru.ID SDK into the journeys of existing accounts that use a mobile phone number instantly enables possession-based security for every user. Furthermore, with no additional input required from the user, there is no attack vector for malicious actors: SIM-based authentication is invisible, so there are no credentials or codes to steal, intercept, or misuse.
tru.ID does not access the user’s SIM card. Instead, it verifies the status of the SIM card directly with the mobile operator in real time. It checks that a phone number has not been assigned to another SIM and that there have been no recent changes to it, helping to prevent SIM swap fraud.
An example scenario for enabling SIM-based verification
Although there are a number of processes described in the scenario below, the end user of the system only has to do one thing: provide their mobile phone number.
- Once the user provides their mobile number, the tru.ID API performs a lookup on the phone number to determine which mobile network operator (MNO) it is assigned to.
2 – tru.ID requests a unique verification URL from the MNO to begin the mobile authentication workflow.
3 – tru.ID stores the MNO verification URL and returns a tru.ID verification URL to your web server for the mobile device to open.
4 – The mobile application opens the tru.ID verification URL. It is preferable to use tru.ID SDKs for this because it forces the web request to be over a mobile data session.
5 – The MNO will receive the web request via a redirect from the tru.ID platform.
6 – The final redirect takes the device to the endpoint of the web server redirect URL. The body of this request will contain a “code” and the “check_id,” and the web server sends this code to the tru.ID API to complete the SubscriberCheck process.
7 – The MNO then determines whether the phone number associated with the authenticated mobile data session matches the phone number associated with the requested verification URL. If it does, the phone number has been successfully verified.
8 – tru.ID performs a SIM card lookup and stores the result of its status.
9 – Upon completion of the verification URL request, and when the SIM card status has been retrieved, the mobile application can request the phone verification result from the tru.ID API.
10 – Use the phone verification and SIM card change properties no_sim_change within your application logic.
Conclusion
The SIM as a “possession factor” helps, but it is not a silver bullet
Using the mobile line to verify the user greatly reduces traditional phishing for credentials and links, but it does not “end” it. Vectors such as SIM swapping/port-out, SS7, malware on the device, and social engineering persist.
Avoid confusing “SIM-based” with SMS OTP
SMS/call (PSTN) codes are now a mechanism restricted by NIST due to their exposure to number hijacking, SIM swapping, and portability fraud. If the telephone channel is used, additional safeguards are required; better yet, do not rely on SMS OTP.
Strategic objective: Phishing-resistant MFA (FIDO2/Passkeys)
To eliminate credential phishing and man-in-the-middle attacks at the root, the goal should be FIDO2/WebAuthn (passkeys, security keys) or equivalent phishing-resistant solutions. This is also the direction set by the latest guidelines.
If you adopt network/SIM-based authentication, add risk controls
Integrate signals such as SIM change detection, recent portability, and device binding before relying on that factor. Have step-up flows if there is risk (new location/device).
Harden the operational perimeter against SIM swapping
Set up portability PINs with the carrier, block the line against unauthorized duplicates, enable SIM change alerts, and educate users/help desk to react to sudden signal loss and unsolicited MFA approvals.
Recommended business transition plan
- Short term: Disable SMS as the preferred method; leave it only as a break-glass with approval and logging.
- Medium term: Deploy passkeys for web and mobile apps; conditional access and number matching to reduce push fatigue.
- Long term: Eliminate passwords in key apps and completely phase out PSTN OTP.
Voice verification and Caller-ID can be falsified; there are studies that demonstrate practical bypassing of countermeasures and call spoofing. Do not rely on telephony as strong verification.
Be careful with voice/biometrics channels per call
