Why Do I Have to Prove Who I Am, But the Website Doesn't?

Every day, something slightly strange happens billions of times across the internet.

You visit a bank, an employer portal, a healthcare application or an online store.

And almost immediately, it begins questioning you.

• What's your username?

• What's your password?

• What's the code we just sent you?

• Do you have your phone?

• Can you approve this notification?

• Can you provide your fingerprint or face?

All perfectly reasonable questions.

The organization wants to know that you are really you.

But there's a question I've been asking for years that turns this entire interaction around:

How do I know that you are really you?

Think about that for a moment.

We have built increasingly sophisticated technologies requiring people to establish their identities to organizations.

Yet when it comes to establishing the identity of the organization on the other side, much of the responsibility still falls on the person sitting in front of the screen.

• Check the URL.

• Look for something suspicious.

• Don't click the wrong link.

• Recognize the phishing page.

• Notice the slightly misspelled domain.

Don't trust the wrong QR code.

Don't be fooled by the email.

And now:

Don't believe everything you see or hear, because AI may have created that too.

Somewhere along the way, we made one participant prove identity while asking the other participant to exercise good judgment.

I think we can do better.

Authentication Grew Up Around the Wrong Assumption

There are historical reasons authentication developed this way.

Early computer systems weren't built around two strangers meeting somewhere on a hostile global network.

You authenticated to your company's computer.

You knew where you were.

The organization controlled the terminal, network and application.

The principal uncertainty was the person sitting at the keyboard.

So the computer asked:

Who are you?

That model made sense.

Then computing changed.

Applications moved to the web.

Banking moved online.

Commerce moved online.

Healthcare moved online.

Work moved to the cloud.

The trusted terminal disappeared.

The internet became the network.

But one fundamental assumption largely survived:

The user still has to prove themselves to the system.

We added stronger passwords.

Then security questions.

Then one-time codes.

Then MFA.

Then authenticator apps.

Then biometrics.

Then passkeys.

We've become considerably better at answering:

“Is this really the user?”

But the internet created another equally important problem:

“Is this really where the user intended to go?”

Phishing Exploits This Imbalance Beautifully

Consider what happens during a phishing attack.

The criminal doesn't necessarily need to defeat authentication.

Sometimes the attacker simply recreates the place where authentication occurs.

The victim receives a convincing message.

They follow a link.

The page looks familiar.

The logo is right.

The colors are right.

The language sounds professional.

So the fraudulent website asks the victim:

Please prove who you are.

And the victim does.

There's something almost absurd about that interaction when you look at it differently.

The criminal successfully demands proof of identity from the victim without first proving anything meaningful about themselves.

The victim is authentic.

The destination isn't.

Authentication occurred.

Trust failed.

That distinction is becoming increasingly important.

We Put the Security Burden on the Wrong Person

For years, security awareness training has tried to compensate for this architectural weakness.

We've taught people:

• Hover over links.

• Inspect domains.

• Don't trust unexpected messages.

• Look for spelling errors.

• Call the sender.

• Check before clicking.

Those are sensible precautions, and people should continue practicing them.

But look at what we're really doing.

We're asking an accountant, nurse, salesperson, customer, retiree or bank employee to make a cybersecurity judgment before performing an ordinary digital transaction.

And attackers only need them to get that judgment wrong once.

I've spent much of my career around authentication, and one lesson keeps becoming clearer to me:

If millions of legitimate users repeatedly make the same security mistake, eventually we should stop asking only what's wrong with the users and start asking what's wrong with the design.

Human beings are part of the system.

Good security architecture has to account for how people actually behave.

AI Changes the Equation Again

This problem becomes much more serious with artificial intelligence.

For years, we told people to look for signs that something was fake.

• Poor grammar.

• Strange formatting.

• An unusual voice.

• A bad photograph.

• An awkward website.

Those clues aren't disappearing overnight.

But AI is becoming very good at removing them.

A phishing message can be professionally written.

A voice can be cloned.

A face can be generated.

A conversation can be personalized.

A fraudulent website can look convincing.

A message can sound exactly like something your boss might write.

We're approaching a point where “Does this look legitimate?” becomes a dangerously weak security control.

The problem isn't that people suddenly became less intelligent.

The counterfeits became better.

When the appearance of legitimacy can be manufactured cheaply and at scale, we need stronger evidence of legitimacy.

Stronger User Authentication Doesn't Solve the Whole Problem

This is also why I think some discussions about MFA and passkeys miss the larger issue.

Passkeys are an important improvement.

Phishing-resistant authentication is an important improvement.

Biometrics can be extremely useful.

Cryptographic credentials are vastly preferable to many of the authentication methods we've depended upon historically.

We should continue improving all of them.

But there's a broader architectural question:

What exactly are we authenticating into?

A strong credential solves one part of the trust relationship.

It doesn't automatically solve every problem surrounding enrollment, recovery, sessions, endpoints, authorization, intent or destination legitimacy.

This is a principle worth remembering:

A strong credential can still participate in a weak trust architecture.

Authentication should not be judged solely by the strength of the factor.

We need to look at the entire interaction.

Trust Is a Relationship

This brings us to the underlying problem.

Trust isn't something one party should simply demand from another.

It's a relationship.

Imagine meeting someone you've never seen before in a parking lot.

They approach you and say:

“Before we continue, I'd like to see your driver's license, passport and fingerprint.”

You'd probably have a reasonable response:

“Who exactly are you?”

Yet digitally, we've normalized something remarkably similar.

Organizations ask us to establish increasingly strong evidence of our identity while we frequently establish theirs through branding, familiarity, a browser address bar and our own judgment.

That's not enough anymore.

I believe authentication needs to evolve from:

User → Organization

toward something closer to:

Verified User ↔ Verified Organization

Both participants should have confidence in who is on the other side.

That's a much healthier foundation for Digital Trust.

This Question Led Us Somewhere Interesting

Years ago at Identité®, we began thinking seriously about this asymmetry.

Why should authentication be one-directional?

Why should the user be the only participant expected to prove legitimacy?

That thinking ultimately contributed to our patented Full Duplex Authentication® approach.

The underlying principle is straightforward:

Trust should work both ways.

The legitimate organization verifies the user.

But the legitimate user also receives evidence that they are interacting with the intended organization.

I mention this not to turn the discussion into a product pitch. The larger idea matters more than any single implementation.

The important shift is architectural:

Stop treating the destination as automatically trustworthy.

If Zero Trust taught us not to grant implicit trust simply because something is inside the network, perhaps we should apply similar skepticism to the other side of authentication.

The user shouldn't be implicitly trusted.

Neither should the destination.

And This Isn't Just About Websites Anymore

There's another reason this question matters now.

Soon, the participant making the authentication decision may not always be human.

AI agents are beginning to interact with applications and services on our behalf.

An autonomous agent may eventually:

• access accounts,

• move information,

• initiate transactions,

• communicate with customers,

• change configurations,

or instruct another agent to perform an action.

Humans have at least some abilities to notice when something feels wrong.

Machines operate differently.

An agent may simply follow an instruction, credential or protocol.

So, the question becomes even more important:

How does the agent know the destination is legitimate?

And then another:

How does the destination know the agent is legitimate?

Suddenly authentication begins to look less like:

“Prove who you are.”

and much more like:

“Let's establish who everyone participating in this interaction actually is.”

That is a fundamentally different trust model.

Attackers Increasingly Want to Inherit Trust

There's another reason we need to think beyond the login.

Modern attackers don't always try to smash through the front door.

Why would they if they can acquire the key?

• They steal credentials.

• Hijack sessions.

• Compromise trusted devices.

• Abuse legitimate remote-management software.

• Operate through approved cloud services.

The objective is increasingly to look like something the environment already trusts.

As I've written before:

Increasingly, the attacker's objective isn't to break trust. It's to inherit it.

That means even successful authentication can't become permanent proof that everything following it is legitimate.

Trust has to remain conditional.

• Who is acting?

• What are they authorized to do?

• Does the action make sense?

• Is the context consistent?

• Is the destination still legitimate?

• Has anything changed?

Authentication should establish trust.

It should not create unlimited trust.

Maybe We've Been Asking the Wrong Question

For decades, the authentication industry has concentrated enormous effort on answering:

How can the organization know this is really the user?

We should continue answering that question.

But perhaps the future of authentication depends just as much on answering its mirror image:

How can the user know this is really the organization?

And increasingly:

How can every legitimate participant establish confidence in every other participant?

That's where authentication begins to become something larger.

It becomes Digital Trust.

The Future Should Require Less Guessing

I don't want people becoming better URL inspectors.

I don't want employees spending their careers learning increasingly sophisticated ways to recognize AI-generated deception.

And I certainly don't believe the answer is adding endless friction to every digital interaction.

Technology should carry more of that burden.

• Verify identity.

• Verify destination.

• Use cryptographic evidence where possible.

• Understand context.

• Consider intent.

• Apply authorization appropriately.

• Continue evaluating trust after authentication.

And make the legitimate interaction easier than the fraudulent one.

Because the ultimate objective isn't to make authentication more complicated.

It's to make deception harder.

For years, organizations have quite reasonably asked us:

“Prove who you are.”

Perhaps it's time users became equally comfortable asking:

“You first.”

That may sound like a small change in perspective.

I think it's the beginning of a much larger one.

Verifiable Identity is the cornerstone of Digital Trust.

And Digital Trust shouldn't belong to only one side of the conversation.