For years, cybersecurity strategy was built around a relatively simple assumption: keep attackers outside the network.
We built firewalls. We segmented networks. We deployed endpoint protection, intrusion detection, vulnerability management and increasingly sophisticated monitoring.
Then the enterprise changed.
Applications moved to the cloud. Employees began working from everywhere. SaaS platforms multiplied. APIs connected systems that had never previously communicated. Contractors, partners, machines and now AI agents became participants in the enterprise.
The perimeter didn't disappear.
It moved to identity.
That is why a recent Cybersecurity Dive article by Eric Geller deserves attention. Drawing on research from ReliaQuest, the article reports that identity-related weaknesses accounted for 44% of true-positive cloud security alerts, while identity issues represented 33% of raw cloud security posture alerts requiring investigation. ReliaQuest also found that privilege escalation accounted for 52% of confirmed identity-based alerts.
Those numbers are significant.
But I believe the more important question is what they tell us about the way attackers are changing the economics of cybercrime.
Why Attack the Technology When You Can Become a Trusted User?
One of the most revealing lines in the ReliaQuest research is also one of the simplest:
“Attackers Aren't Breaking In—They're Logging In.”
That distinction matters.
An attacker exploiting a vulnerability often creates evidence of an attack. Scanning systems, executing exploit code and probing infrastructure can generate signals defenders know how to recognize.
A valid credential behaves differently.
It opens the door.
And once the system recognizes the credential, much of what happens afterward can resemble legitimate activity.
ReliaQuest reports that compromised credentials can be purchased for very little money on criminal marketplaces. The firm observed basic credentials available for as little as $2, while cloud access keys and other higher-value credentials can also leak through repositories, CI/CD pipelines, malware and misconfigured environments.
That changes the attacker's objective.
Why spend time defeating every security control when you can become someone those controls have already been taught to trust?
That is the deeper identity problem.
The Credential Can Be Valid While the Person Using It Is Not
This is where organizations need to be careful about what we mean when we say an identity has been “verified.”
A username can be correct.
A password can be correct.
A credential can be legitimate.
A session can appear normal.
And the person behind all of it can still be the attacker.
That is why identity security cannot stop at the question:
Did this person provide an acceptable credential?
We increasingly need to ask several questions:
Who is requesting access?
Who or what are they communicating with?
Was this authentication actually initiated by the legitimate user?
What is this identity authorized to do?
Does the requested action make sense in this context?
These are related questions, but they are not the same question.
And that distinction becomes especially important once the attacker gets through the first door.
99% Over-Privileged Should Make Every Security Leader Uncomfortable
Perhaps the most startling statistic in the ReliaQuest research is its citation of research finding that 99% of cloud identities are over-privileged.
Think about what that means from the attacker's perspective.
Stealing an identity isn't necessarily the end goal.
It is the beginning.
If that identity possesses permissions far beyond what the legitimate user actually requires, the attacker may inherit those privileges as well.
ReliaQuest found that 52% of confirmed identity-related alerts involved privilege escalation. The report argues that abusing legitimate credentials with excessive permissions can be considerably stealthier than techniques such as vulnerability scanning or exploit execution.
This is why authentication and authorization must be treated as different security decisions.
Authentication asks:
Who are you, and can you prove it?
Authorization asks:
Now that we believe we know who you are, what should you be allowed to do?
Those two decisions have been allowed to collapse into one another for too long.
A successful login should not automatically create broad, persistent authority.
Authentication Opens the Door. Authorization Determines What Happens Next.
Imagine an employee who legitimately needs access to a financial system.
Authentication establishes the employee's identity.
But should that authentication automatically authorize the employee to change banking information, export thousands of records, create a privileged administrator, initiate a large financial transaction or access sensitive information outside their normal responsibilities?
Of course not.
Those actions carry different consequences.
And different consequences should require different levels of trust.
ReliaQuest recommends moving toward zero standing privileges, where permissions are provided only when required and then expire. It specifically advocates just-in-time access and short-lived credentials rather than unnecessarily persistent permissions.
That is an important architectural shift.
But there is another question we should add.
Who authorized the consequential action?
Because reducing privileges limits what a compromised identity can reach.
Strong authorization determines what that identity should be permitted to do at that particular moment.
The Identité® Perspective: Trust Should Not Travel in Only One Direction
There is another dimension of identity security that becomes increasingly important as attackers improve their ability to impersonate legitimate organizations.
Traditional authentication has largely concentrated on one relationship:
User → Organization
The organization challenges the user.
Prove your identity.
Enter your password.
Provide your MFA code.
Approve the notification.
Present your biometric.
But attackers have become extremely good at inserting themselves into that relationship.
They create convincing login pages. They impersonate trusted organizations. They initiate fraudulent authentication requests. They socially engineer users. They steal credentials and sessions.
Which raises a deceptively simple question:
If the organization requires me to prove that I am really me, why shouldn't I require the organization to prove that it is really the organization I intended to reach?
This is the problem Identité® addresses through Full Duplex Authentication®.
Instead of authentication operating in only one direction:
User → Destination
the trust relationship becomes:
User ↔ Legitimate Destination
Both sides participate in establishing trust.
The objective is not simply to add another authentication factor.
It is to make the trust relationship itself harder to counterfeit.
Intent Is Becoming Part of Identity
There is another problem hiding inside identity-based attacks.
A user can successfully complete an authentication challenge without understanding why the challenge appeared.
We have seen this problem with MFA fatigue and push bombing.
A notification appears.
The employee is busy.
Maybe it is the fifth authentication request that morning.
They approve it.
Technically, the user participated in authentication.
But did they actually request the session?
Those are not necessarily the same thing.
That is why Identité's approach can explicitly present authentication context and ask:
“Did you request this authentication session?”
That seemingly simple question introduces something important into the security decision:
intent.
Identity tells us who the person is.
Authentication provides evidence supporting that identity.
Intent helps establish whether the interaction is actually theirs.
Authorization determines what that identity should be allowed to do.
Full Duplex Authentication® helps establish trust in the other side of the interaction.
Put together, we begin to see a more complete trust architecture.
The New Trust Framework
The future of identity security may therefore require us to think beyond authentication as a single event.
The framework becomes:
Identity. Destination. Intent. Authorization. Context. Trust.
Who are you?
Who are you talking to?
Did you request this interaction?
What are you trying to do?
Are you authorized to do it?
Should that authority exist permanently, or only for this action?
Does the context surrounding the request make sense?
These questions become even more important as enterprises introduce AI agents and machine identities into cloud environments.
An AI agent may authenticate successfully.
That does not mean it should inherit unlimited human authority.
A machine identity may be legitimate.
That does not mean it should possess permanent credentials capable of accessing every resource its human owner can reach.
The number of identities is increasing.
The speed at which those identities can act is increasing.
The consequences of misplaced trust are increasing with them.
Stronger Security Should Not Mean More Friction Everywhere
There is an understandable concern that all of this will make authentication more complicated.
It shouldn't.
The objective should not be to challenge legitimate users constantly.
It should be to make trust more intelligent.
Low-risk actions with strong identity assurance, legitimate destinations, expected behavior and appropriate privileges should create very little friction.
Higher-risk actions should trigger stronger authorization.
The principle is straightforward:
Friction should follow risk.
That is better security and, when designed properly, a better user experience.
The legitimate employee gets to work.
The suspicious transaction gets challenged.
The over-privileged identity gets constrained.
The fraudulent destination fails to establish trust.
Security stops treating every interaction equally and begins protecting the interactions that actually matter.
Cloud Security Has Become a Trust Problem
ReliaQuest's findings deserve attention because they reveal something larger than an IAM configuration problem.
The company describes identity as the modern perimeter and argues that defenders need to connect identity, cloud and endpoint signals rather than fighting isolated fragments of an attack chain.
I agree.
But I would take the argument one step further.
Identity may be the modern perimeter.
Trust is becoming the modern control plane.
As organizations become more distributed, the security question is increasingly not simply whether someone crossed a network boundary.
It is whether the person, machine, destination and requested action deserve the trust the system is about to give them.
That is a fundamentally different security model.
And it explains why adding another authentication challenge cannot, by itself, solve the identity problem.
The future of authentication will require us to establish trustworthy relationships, verify intent, limit authority and continuously reconsider what an authenticated identity should be allowed to do.
Cybersecurity Dive and ReliaQuest have provided compelling evidence of where cloud attacks are moving.
The larger lesson is where security architecture must move next.
Attackers don't have to defeat every security control. They only have to become someone, or something, those controls have been taught to trust.
The future of prevention begins by making that trust much harder to counterfeit.