ASK-Solutions

Background article in Technology & Society.

Multi-factor authentication sounds wonderfully sensible. First a password, then something extra: a code, app, key, fingerprint, phone prompt or passkey. As if your front door had not only a lock, but also briefly asked whether you are actually you.

That is often exactly what we want. Passwords leak, get reused, guessed, intercepted and sometimes stored as if an intern with a spreadsheet was the chief architect. A second factor can prevent a lot of damage.

But the security question is not the only question. Once a service says "for your security we also need your phone number, device ID, recovery email, app installation, push notifications, location context and behaviour signals", the subject shifts from security to data collection.

And that is where the privacy question begins: when does MFA protect the user, and when does MFA become a tidy front door into a larger profile cabinet?

MFA is not the enemy

Let us be clear first: MFA is basically good. An account protected only by a password is vulnerable, especially when the same password has been used in more than one place. A second factor makes abuse harder.

Not every second factor is equally strong. A hardware security key or passkey is usually more resistant to phishing than a loose SMS code. An authenticator app is often better than email alone. SMS can still be better than nothing, but the phone network and phone number are not a magic security layer.

That distinction matters. Criticising privacy-hostile MFA does not mean saying: "send everyone back to password123." That would not be a privacy strategy, but digital self-punishment in capital letters.

The better position is simpler: use MFA, but design it soberly. Do not collect more data than needed. Do not use security data for marketing, profiling or account linking. And where possible, give users privacy-friendly options.

Fact and fiction

This discussion needs a clean separation.

Fact: MFA helps against many forms of account abuse. That is why security organisations keep recommending it. Phishing-resistant methods in particular, such as FIDO2 security keys and well designed passkeys, reduce dependence on shared codes that an attacker can capture.

Fact: phone number, recovery email, device characteristics, IP address, timestamp, app use and push-response behaviour can be personal data, or at least identifiable metadata. They do not always reveal what someone does, but often reveal enough to connect accounts, devices and patterns.

Fact: data collected for security can later be used for other purposes when rules, technology or internal incentives allow it. The FTC case against Twitter is a clear example: according to the regulator, phone number and email data provided for account security were also used for targeted advertising.

Not proven: that MFA as a concept is a disguised data grab. A well designed second factor can be privacy-friendly, especially when biometrics stay local, every website gets its own cryptographic key and the provider does not store unnecessary profile information.

Plausible: larger databases become more attractive. Not only to attackers, but also to internal analytics, risk models, advertising goals, fraud detection, customer retention and "personalisation". A field called "security_phone" today can become "useful_customer_identifier" in someone's dashboard tomorrow. The database will not blush.

The phone number as profile anchor

The phone number is practical. Many people have one, it is relatively stable and it works outside the app. That is why services like using it for recovery and verification.

But those same properties make the phone number privacy-sensitive. A phone number can connect accounts, expose address-book relationships, introduce SIM-swap risks, enable spam and make a person recognisable across services.

When a service makes SMS MFA mandatory without an alternative, it is not only asking for a second factor. It is asking for an identifier that often sits closer to the real person than a username. For some users, that is not a detail but a security or privacy risk.

So "give us your phone number for your security" is not automatically wrong, but it is not automatically innocent either. The right follow-up question is: can the same security be achieved with less personal data?

More data is not the same as better security

Companies like adding layers: recovery questions, extra email addresses, phone verification, device fingerprinting, location checks, push apps, risk scores and suspicious-login models. Some of these are useful. Some mainly move uncertainty into a larger pile of data.

Security is not a competition to see who can fit the most fields into a form. A secret question such as "what was your first pet's name?" does not become secure because it appears in a tidy security flow. Many answers can be guessed, found or reused from breaches.

Behavioural analysis and device profiling can also be useful for fraud detection, but they must remain proportionate. If a simple newsletter sign-up gets the same appetite for device and location data as online banking, something has tilted.

That is where "security" sometimes becomes security theatre: a lot happens, it looks serious, but the user does not always receive clearly better protection. What does arise is a richer database.

Purpose limitation is not paperwork

Under European privacy rules, purpose limitation and data minimisation are not polite suggestions. Personal data must be collected for clear purposes and limited to what is necessary for those purposes.

That principle fits MFA particularly well. If a phone number, recovery email or device registration is needed for account security, use that data for account security. Not for advertising. Not for general profiling. Not for silent linking with other services because the technology happens to be feeling sociable.

The problem is not that a security team wants to assess risk. The problem begins when the organisation fails to draw a firm boundary between security data and customer profile data.

For users, that difference is often invisible. You see a screen asking for extra security. Behind that screen, storage, analytics, advertising technology, customer support, fraud detection and identity management may all want something from the same data. That requires governance, not only a privacy policy nobody reads without caffeine and character.

Better MFA exists

Fortunately, this is not a choice between weak passwords and data hunger. Better forms of MFA exist.

Hardware security keys and FIDO/WebAuthn-based passkeys use public-key cryptography. The service does not receive a shared code that can later be intercepted again. The key is also different per service, so websites cannot simply track each other through the same key.

Biometrics can sound confusing here. In well designed passkeys, your fingerprint or face recognition does not leave the device as a password replacement sent to the website. Biometrics unlock a key locally. That is very different from a central database full of biometric profiles.

Authenticator apps can also be reasonably privacy-friendly when they generate offline codes and do not force an account, tracking or cloud link. The little code in the app is boring, but sometimes boring is exactly what security needs.

What companies should do

A privacy-friendly MFA policy starts with choice. Offer several strong options: passkeys, hardware keys, authenticator apps and, where needed, SMS as a fallback rather than the only gate.

Then draw a hard line around purpose. Data requested for security should not disappear into marketing profiles. Someone giving a phone number to avoid being hacked has not silently agreed to better advertising audiences.

Limit retention. Explain which data is stored. Show which recovery options are active. Let users remove old devices and phone numbers. Make export and correction possible where the law requires it. And do not use dark patterns where "set up later" is hidden as if it were a moral failure.

For organisations, this is also self-interest. Every extra database column has to be secured, explained, managed, audited and eventually defended when it leaks. Less data is not only better for privacy; it is also less mess to write incident reports about at three in the morning.

What users can ask

Users do not need to become cryptographers to make better choices. A few questions already help.

• Can I use a passkey, hardware key or authenticator app instead of SMS?
• Is my phone number used only for security and recovery?
• Can I remove old devices, sessions and recovery methods myself?
• Is there a recovery procedure that does not depend on one phone number?
• Can I use MFA without a mandatory tracking app?
• Is it clear which data is stored and for how long?

For important accounts, strong MFA is sensible. For sensitive situations, a hardware key or passkey may be better than a phone number. For less important services, users may reasonably be sceptical when a sock webshop behaves as if it has the same risk profile as a bank.

The right size

The honest answer is therefore double. Yes, MFA matters. No, that does not make every MFA flow automatically privacy-friendly.

Security must not become an excuse to build an ever larger profile of the user. The goal is not for companies to know more about you. The goal is that someone else cannot log in as you.

The right direction is sober and strong: phishing-resistant MFA where possible, minimal data collection, clear purpose limitation, real deletion options and no reuse of security data for commercial profiling.

MFA should be an extra lock on your account, not an extra shelf in the file about you. Once security respects that boundary, it becomes stronger for the user instead of more valuable for the database.

Sources

CISA	Multi-factor authentication	More than a Password: multi-factor authentication guidance
CISA	Phishing-resistant MFA	Implementing phishing-resistant MFA
NIST	Digital Identity Guidelines	SP 800-63B: Authentication and authenticator management
FTC	Twitter enforcement	FTC charges Twitter with deceptively using account security data to sell targeted ads
EUR-Lex	GDPR	Regulation (EU) 2016/679: purpose limitation and data minimisation
EDPB	Privacy by design	Guidelines on Data Protection by Design and by Default
FIDO Alliance	Passkeys	Passkeys and phishing-resistant authentication