For years, the cybersecurity industry followed what seemed like a logical progression.
Passwords were not enough.
So, we added another factor.
Two-factor authentication, or 2FA, represented a significant improvement over relying solely on a username and password.
But attackers adapted.
Credentials were stolen. SMS messages could be intercepted or redirected. Users could be socially engineered. One-time codes could be phished.
So, the industry responded again.
More factors. More verification. More security.
Multi-factor authentication became the new standard.
For a long time, MFA was viewed as the king of the hill when it came to authentication. If passwords were weak and 2FA could be defeated, MFA appeared to provide the additional protection enterprises needed.
And MFA absolutely represented progress.
But attackers adapted again.
A Cybersecurity Dive article based on research from Cisco Talos caught my attention because it illustrates the problem particularly well. MFA was involved in almost half of the security incidents handled by Cisco Talos incident response teams during the period examined. Fraudulent MFA push notifications appeared in 25 percent of cases, while improperly implemented MFA appeared in one out of five engagements.
Attackers were also using stolen authentication tokens, social engineering against IT departments and compromised third parties to get around MFA protections.
Those findings raise a question I believe the cybersecurity industry needs to confront:
How many more layers are we going to add before we reconsider the foundation underneath them?
MFA Is Still Better Than Passwords Alone
This discussion requires an important distinction.
The lesson should not be:
"MFA doesn't work, so stop using it."
That would be the wrong conclusion.
Properly implemented MFA remains substantially preferable to relying on passwords alone. The Cybersecurity Dive article itself notes that Cisco Talos considers even basic SMS-based MFA better than having no MFA, while recommending stronger implementations.
The problem is more fundamental.
Much of MFA still attempts to solve the weaknesses of traditional authentication by adding additional verification around the same basic architecture.
Username.
Password.
Second factor.
Maybe another challenge.
Maybe another notification.
Maybe another code.
We keep strengthening the fortress.
But the underlying transaction remains largely the same.
The user is being asked to prove themselves to the destination.
And that is where I believe we need to start thinking differently.
We Keep Protecting the Password Instead of Replacing the Problem
Think about how we arrived here.
Passwords became vulnerable, so we made them longer.
Attackers cracked them, so we required complexity.
Users forgot them, so we created reset mechanisms.
Attackers exploited those mechanisms.
Passwords were stolen, so we added SMS codes.
SMS became vulnerable, so we added authenticator applications.
Attackers began phishing one-time codes.
So, we added push notifications.
Attackers responded with push fatigue and social engineering.
So, we added number matching and additional prompts.
Every improvement makes the attacker's job harder.
But the attacker keeps adapting.
This should tell us something.
Complexity is not the same thing as trust.
We can continue adding security layers around a vulnerable authentication model, but eventually we need to ask whether the architecture itself needs to change.
MFA Fatigue Demonstrates the Human Problem
The Cisco Talos findings surrounding fraudulent push notifications are particularly important because they expose another weakness in conventional authentication:
The human being becomes part of the attack surface.
Cisco Duo analyzed 15,000 push-based attacks between June 2023 and May 2024. Researchers found attackers strategically targeting certain times of day, including pre-work hours when employees may be checking phones and preparing for the workday.
Think about the attacker's strategy.
The attacker does not necessarily need to break the cryptography.
They may simply need to confuse, fatigue or manipulate the person.
Send enough requests.
Choose the right moment.
Create urgency.
Impersonate IT support.
Convince the employee that approving the request will make the problem disappear.
Eventually, someone may click Approve.
The technology might function exactly as designed.
The authentication still fails because the human was manipulated.
An Authentication Request Should Explain Itself
This is one reason we believe authentication needs context.
A generic push notification asking:
"Approve?"
places too much responsibility on the user while providing too little information.
Approve what?
Did I initiate this?
Which application generated it?
Why am I receiving it?
What happens if I approve?
At Identité, we approach this differently.
The authentication screen can explicitly ask:
"Did you request this authentication session?"
On that same screen, an image and three-digit number can provide additional context associated with the authentication interaction.
That may seem like a subtle distinction.
It isn't.
The objective is to move users away from reflexive approval and toward confirmation of intent.
Authentication should not merely establish:
"Can this person respond to a challenge?"
We should also be asking:
"Did this person actually intend to authenticate?"
But There Is Still Another Problem
Even stronger user authentication leaves one enormous question unanswered.
We spend tremendous amounts of money determining:
"Are you really you?"
But how often does the system prove:
"Am I really who you think I am?"
Consider phishing.
A user receives an email appearing to come from a bank, employer, hospital, school or government agency.
They click a link.
The website looks legitimate.
The logo is correct.
The colors are correct.
The language is convincing.
The login page appears identical.
The domain may differ by only a character.
Now add artificial intelligence.
Attackers can increasingly create convincing communications, websites, support interactions and social-engineering campaigns at extraordinary speed and scale.
The user may authenticate perfectly.
But they may be authenticating to the wrong destination.
That is a fundamental weakness of one-way authentication.
Authentication Should Work in Both Directions
This is the principle behind Identité's patented Full Duplex Authentication®.
Traditional authentication primarily focuses on authenticating the user to the destination.
We believe digital trust should be mutual.
The user must establish legitimacy.
The destination must establish legitimacy too.
That changes the equation.
Instead of: User → Website
we move toward: User ↔ Legitimate Destination
Both sides participate in establishing trust.
This is particularly important when dealing with phishing and lookalike websites.
An imposter website may reproduce what a legitimate institution looks like.
But appearance is not identity.
A fraudulent website should not be able to perform the legitimate destination's side of a mutual authentication relationship simply because it copied the organization's logo and login page.
That is why we believe the industry eventually has to move beyond adding more factors to one-way authentication.
MFA Is Still Primarily Asking One Side to Prove Itself
This is the distinction that matters.
Password authentication asks the user to prove themselves.
2FA asks the user to prove themselves with another factor.
MFA asks the user to prove themselves with multiple factors.
Stronger factors improve security.
But the basic relationship can still remain:
Prove yourself to me.
Full Duplex Authentication® changes the question:
Let's establish who both of us are.
That is a fundamentally different trust model.
And in a digital world increasingly dominated by impersonation, phishing, AI-generated deception and lookalike destinations, mutual authentication deserves much greater attention.
Authentication Is Only the Beginning
There is another problem with treating MFA as the finish line.
Even perfect authentication should not provide unlimited authority.
Suppose a bank customer successfully authenticates.
The bank now has strong confidence in the customer's identity.
Does that mean the customer should automatically be permitted to perform every possible transaction?
Of course not.
Authentication answers:
"Are you really the account holder?"
Authorization answers:
"Are you permitted to perform this particular action?"
Imagine the customer checks an account balance. There is little reason to introduce unnecessary friction.
They review transactions. Again, let the experience remain simple.
Then they attempt to wire $10,000 to a new recipient.
The risk has changed.
The security response should change too.
If the bank has established a policy requiring additional authorization above a particular threshold, the transaction can automatically invoke authorization.
The customer is now confirming something different:
"Yes, I authorize this specific transaction."
That creates a much stronger security model.
Identity + Authentication + Authorization + Intent + Destination
This is where I believe authentication needs to evolve.
Stop thinking exclusively in terms of how many factors we can stack on top of a login.
Start thinking about digital trust.
We need to establish:
Identity: Who are you?
Authentication: Can you prove it?
Authorization: Are you permitted to perform this action?
Intent: Did you actually initiate or request it?
Destination: Are you interacting with the legitimate organization?
Add context, least privilege and continuous verification, and we begin moving toward something much more powerful than traditional MFA.
We begin building a trust architecture.
Zero Trust Should Mean Zero Assumptions
This approach also fits naturally with Zero Trust.
Zero Trust should not mean repeatedly interrupting legitimate users with more authentication prompts.
It should mean:
Assume nothing. Establish what matters.
Do not assume possession of a password establishes identity.
Do not assume successful MFA creates unlimited trust.
Do not assume an authenticated user should have unrestricted access.
Do not assume an authentication request was intentionally initiated.
Do not assume a familiar-looking website is legitimate.
Do not assume yesterday's authorization applies to today's high-risk transaction.
Verify identity.
Authorize the action.
Establish intent.
Verify the destination.
Apply least privilege.
Reevaluate when the risk changes.
That is a much more complete interpretation of Zero Trust.
Less Friction Can Actually Produce Better Security
There is another lesson in all of this.
The answer to authentication weakness cannot always be:
Make the user do more.
Another password requirement.
Another code.
Another application.
Another notification.
Another approval.
Another security step.
At some point, friction itself creates risk.
People become fatigued.
They develop workarounds.
They click without reading.
They resent security.
Help desks become overloaded.
Productivity suffers.
Customers abandon transactions.
The objective should be the opposite:
Make authentication easier for legitimate people and substantially harder for attackers.
That requires greater confidence, not greater complexity.
At Identité, our approach uses a trusted device and decentralized biometric verification to help establish the legitimate user without requiring biometric data to reside in a centralized Identité biometric repository.
The biometric remains on the user's device.
Full Duplex Authentication® addresses the legitimacy of the destination.
Authentication intent provides additional context.
Authorization can protect consequential actions after authentication.
The result is not about adding another factor.
It is about improving the trust relationship itself.
PasswordFree® for SaaS
Identité's PasswordFree® is our SaaS passwordless authentication solution.
PasswordFree® is designed to move organizations beyond dependence on traditional passwords while incorporating capabilities such as patented Full Duplex Authentication®, trusted-device authentication, decentralized biometric verification, authentication intent, contextual authentication, Emergency PIN Authentication and Secure Backup & Restore.
The objective is not simply password elimination.
It is stronger digital trust with less unnecessary friction.
For customers and employees, authentication should increasingly become something that enables the experience rather than dominates it.
NoPass™ for Enterprise Environments
For organizations requiring deeper enterprise integration and infrastructure control, Identité offers NoPass™, our PaaS solution powered by patented Full Duplex Authentication®.
NoPass™ can be deployed on premises or in the cloud and can support environments involving Microsoft Active Directory, Microsoft Entra ID, Microsoft 365 / Office 365 and Microsoft Azure.
That flexibility is particularly important for banks, healthcare organizations, government agencies and other enterprises that require greater control over sensitive authentication environments.
Banks in particular often prefer on-premises deployment because they are highly sensitive to placing customer or critical information in cloud environments.
The architecture can adapt to the organization's requirements.
The organization should not have to weaken its requirements to accommodate the authentication architecture.
Hospitals, Schools and Governments Face the Same Problem
Although enterprises and banks are obvious targets, this issue extends much further.
Hospitals authenticate physicians, nurses, administrators and patients.
Schools authenticate teachers, students, parents and administrators.
Government agencies authenticate employees, citizens and contractors.
Businesses authenticate employees, partners and customers.
Financial institutions authenticate customers, employees and transactions.
Every one of these environments faces the same fundamental challenge:
How do we establish digital trust without making legitimate people jump through increasingly complicated hoops?
The industry has spent decades answering that question by adding more authentication factors.
Perhaps the next phase requires a different answer.
The Identité Perspective: Stop Adding Layers. Change the Relationship.
Passwords were not enough.
So, we added another factor.
2FA was not enough for every threat.
So, we expanded to MFA.
Attackers adapted.
Now we are adding stronger factors, phishing-resistant technologies, contextual controls and additional verification.
Many of those improvements are valuable and organizations should absolutely strengthen vulnerable MFA implementations.
But we should not mistake improving the existing model for solving the underlying problem.
As long as authentication remains fundamentally one directional, the user can still be placed in the position of proving themselves to something they assume is legitimate.
And as long as successful authentication is treated as sufficient authority, organizations remain exposed to what happens after the login.
That is why the next generation of authentication must address more than factors.
It must address identity.
It must address intent.
It must address authorization.
It must address the legitimacy of the destination.
It must address friction.
And above all, it must address trust in both directions.
MFA was an important step forward.
It still has an important role today.
But we should stop asking:
"How many more factors can we add?"
And start asking:
"Why are we still authenticating in only one direction?"
Because until digital trust becomes mutual, attackers will continue searching for ways around whatever additional layer we put in front of them.
The future is not simply more authentication.
The future is better authentication.
And better authentication begins when both sides establish who they are.