When stolen credentials open the door to sensitive information, we need to ask two questions: Who are we letting in, and what are we allowing them to do once they're inside?
It Began With Something We Do Every Day. Trust Someone.
Imagine you're at work when someone contacts you claiming to be from your company's IT department.
They sound professional. They know enough about your organization to appear legitimate. They tell you there's an issue with your account and they need your help resolving it.
You cooperate.
After all, they're from IT. Right?
Except they're not.
And what seems like an ordinary interaction can become the beginning of an extraordinary security failure.
According to a November 2026 report from DataBreachToday, a cyberattack against Marathon Health potentially affected nearly 5.7 million individuals.
The reported sequence is disturbingly straightforward. An attacker impersonated an IT worker, obtained an employee's credentials, and used those credentials to access a cloud-hosted application. Information was subsequently exported.
Think about that.
Nearly 5.7 million people potentially affected.
Not necessarily because someone exploited a previously unknown software vulnerability.
Not necessarily because the attacker defeated every security control protecting the organization.
But because an attacker successfully exploited trust, obtained credentials, and gained access to sensitive information.
And that raises a question we don't ask nearly often enough.
When someone presents valid credentials, are we verifying the person, or simply trusting the credentials?
A Valid Credential Doesn't Make Someone Legitimate
For decades, much of digital security has operated on a simple assumption.
If someone provides the correct username and password, they must be the person authorized to use them.
The credentials match. The system opens the door.
But there's an obvious flaw in that reasoning.
What if the credentials have been stolen?
The system may recognize the password perfectly. What it cannot necessarily recognize is that the person entering it is an impostor.
Knowing someone's password doesn't make you that person.
Yet attackers have built an entire industry around exploiting precisely that distinction.
Why spend weeks attempting to break through sophisticated security defenses when you can convince someone to hand over the keys?
Phishing, impersonation, credential theft, and social engineering work because people and systems sometimes mistake familiarity for legitimacy.
And in the Marathon Health incident, the reported use of compromised credentials illustrates how an attacker can exploit a legitimate authentication process to gain unauthorized access.
The credentials may have been valid.
The person using them was not.
But there's another part of this story that deserves just as much attention.
One AUTH Is Not Enough. And Neither Is a Successful Login.
The reported attacker didn't simply enter a cloud-hosted application.
Information was exported.
Those are two different events, and they should prompt two different security questions.
The first is Authentication.
Who are you? Can you prove that you are who you claim to be?
The second is Authorization.
Now that you've established an identity, what are you actually permitted to access or do?
It's a distinction that sounds technical, but the principle is remarkably simple.
Think about entering an office building.
Your employee badge may get you through the front door. That's authentication.
But that doesn't mean your badge should also open the executive offices, the payroll department, the server room, and every locked filing cabinet.
Those permissions are a matter of authorization.
And even if you're permitted to enter the payroll department, that doesn't necessarily mean you should be allowed to walk out carrying every employee's confidential records.
Getting through the front door should never mean having unrestricted access to everything inside.
Now apply that same thinking to the Marathon Health incident.
An attacker reportedly obtained legitimate employee credentials and gained access to an application.
The first security decision failed to distinguish the attacker from the authorized employee.
But what about the second?
What information was that account permitted to access? What restrictions applied to exporting data? Were unusually sensitive actions subject to additional verification?
The public reporting does not establish the answers to all those questions.
But they're precisely the questions organizations should be asking.
Because authentication and authorization are not the same thing.
And successful authentication should never be interpreted as unlimited authorization.
Authorization: The Security Decision That Continues After Login
Here's where the distinction becomes especially important.
Traditional authorization systems often assign permissions based on an employee's role.
An accountant can access financial records.
A healthcare professional can access certain patient information.
An administrator may have broader system privileges.
That makes sense.
But consider what happens when an attacker compromises an account that already possesses legitimate access rights.
The attacker may inherit those same permissions.
If the employee can export sensitive records, the attacker may be able to do so as well.
That's why authorization cannot simply be a static list of permissions established once and then forgotten.
It must be capable of evaluating what someone is attempting to do, the sensitivity of the information involved, and whether the action is appropriate under the circumstances.
For example, an employee who normally accesses individual records might suddenly attempt to download thousands.
A request might originate from an unfamiliar device.
A session might exhibit unusual behavior.
Or someone might attempt an operation that is technically permitted by their role but inconsistent with their normal responsibilities.
Those circumstances should matter.
Organizations can apply least-privilege permissions, restrict bulk exports, evaluate session and device risk, and require stronger verification before particularly sensitive operations.
In some cases, the appropriate response is to deny the action altogether.
There is another important safeguard that deserves consideration. For particularly sensitive operations, authorization can require fresh verification of the legitimate user's presence through a trusted, device-bound authentication mechanism. This may include a biometric check performed locally on the user's device, allowing a protected cryptographic credential to be used without exposing the biometric itself to the application.
Think about what that means for an attacker who has stolen someone's login credentials. Even if those credentials provide initial access, they may not be enough to authorize the extraction of sensitive information. Without access to the legitimate user's trusted device and the ability to satisfy its verification requirements, the attacker could find that the very action they intended to perform is denied. The first security decision may have been compromised, but the second provides an independent opportunity to stop the attack.
Of course, no authorization system can guarantee that every malicious action will be detected. A compromised account may still be used to perform activities that fall within its legitimate permissions.
But that is not an argument against authorization.
It's an argument for making authorization more precise, contextual, and responsive to risk.
Authentication determines whether an identity can enter. Authorization determines what that identity is allowed to do.
Both decisions matter.
And neither should be treated as a one-time exercise in trust.
There's Another Problem. Who Is Authenticating the Other Party?
So far, we've examined what happens when an attacker presents stolen credentials and gains access to a system.
But let's return to the beginning of the Marathon Health incident.
The attacker reportedly impersonated an IT worker.
Before the credentials were stolen, someone had to believe that the person requesting them was legitimate.
That brings us to a larger issue.
We spend enormous amounts of time and money asking users to prove their identities.
- Passwords.
- Verification codes.
- Authenticator applications.
- Biometrics.
- Security questions.
But how often do we ask the equally important question?
What has the person, website, or application requesting our credentials done to prove its identity to us?
Think about the last time you logged into your bank account.
You were expected to prove who you were.
But how did you establish that you were actually communicating with your bank?
Did you independently verify the destination, or did you trust the website because it looked familiar?
Attackers understand this imbalance.
They create convincing login pages. They impersonate trusted employees. They send messages that appear to come from legitimate organizations.
They know that people are conditioned to respond when someone claiming authority asks them to authenticate.
And that's the fundamental weakness of one-sided trust.
We demand proof from the user while too often expecting the user to assume the legitimacy of whoever is asking.
That's not a balanced trust relationship.
And it's certainly not the foundation on which we should build the future of digital identity.
Mutual Trust Changes the Conversation
Trust should be a two-way relationship.
We understand this instinctively in the physical world.
If someone knocks on your door claiming to represent your bank, you don't automatically invite them inside because they know your name.
You ask questions.
You request identification.
You might call the bank using a number you independently know to be legitimate.
You verify before you trust.
Yet in the digital world, we're frequently asked to do the opposite.
- Click the link.
- Enter your password.
- Approve the notification.
- Provide the code.
And assume the party requesting all this information is legitimate.
It doesn't have to work that way.
Mutual Authentication establishes the legitimacy of both parties participating in a digital authentication exchange.
The user proves their identity to the service.
The service proves its identity to the user or the user's trusted authentication mechanism.
Neither side has to rely solely on appearances or an unverified claim.
Modern cryptographic authentication methods can help make this possible without requiring users to become cybersecurity experts.
And when those methods are phishing-resistant, they can make it significantly more difficult for attackers to capture or reuse authentication credentials through fraudulent websites.
But Mutual Authentication is not a universal solution to impersonation.
A cryptographically verified connection to a legitimate application does not automatically establish that someone claiming to be an IT employee over the telephone is legitimate.
Those interactions require their own trusted verification procedures.
The principle, however, remains the same.
No one should be expected to surrender sensitive information or grant access simply because the other party claims to be trustworthy.
Identity must be established.
And trust must be earned by both sides.
MFA Is Important. But More Authentication Doesn't Automatically Mean More Trust.
Multi-Factor Authentication has made an important contribution to cybersecurity.
Requiring an additional factor beyond a password can substantially reduce the risk of unauthorized account access.
But not all MFA methods are equally resistant to attack.
Some verification codes can be phished.
Some authentication requests can be manipulated through social engineering.
Some session information can be stolen after authentication.
And a successful MFA event doesn't necessarily mean every subsequent action should be trusted.
This is why I believe we need to move beyond thinking of authentication as a collection of obstacles users must overcome.
Adding more steps is not the same thing as establishing greater trust.
A stronger approach combines phishing-resistant authentication, appropriate verification of the service, device and session protections, and authorization controls that reflect the sensitivity of the requested action.
The goal is not to make every login more difficult.
The goal is to make impersonation more difficult and unauthorized actions harder to complete.
Those are very different objectives.
And they lead to a much more productive conversation about security.
Trust Shouldn't End at the Login Screen
Here's the larger lesson I take from the Marathon Health incident.
Security isn't a single decision made when someone enters a username and password.
It's a series of decisions throughout a digital interaction.
- Who is requesting access?
- Is that identity legitimate?
- Is the service itself legitimate?
- What information is being requested?
- Is the requested action authorized?
- Does the context justify additional scrutiny?
These questions shouldn't disappear simply because a login was successful.
Consider what stronger security could look like.
- A user authenticates through a phishing-resistant method that does not expose reusable credentials.
- The authentication process verifies that the user is communicating with the legitimate service.
- The organization grants only the permissions necessary for the user's responsibilities.
- When particularly sensitive information is requested, authorization controls evaluate whether that action is appropriate.
- And when circumstances indicate unusual risk, the system can require additional verification, restrict access, or deny the operation.
None of this guarantees that every attack will be prevented.
But it reduces the number of assumptions on which an attacker can depend.
And perhaps most importantly, it changes how we think about trust.
Trust is not a permanent privilege awarded at login. It is a relationship that must be established, protected, and reassessed when circumstances warrant it.
That is a much stronger foundation for digital security.
Behind 5.7 Million Records Are 5.7 Million People
It's easy to become desensitized to cybersecurity headlines.
Another breach.
Another compromised account.
Another organization investigating unauthorized access.
Another number measured in millions.
But behind the reported Marathon Health incident are nearly 5.7 million individuals whose personal information may have been affected.
People who entrusted sensitive information to an organization with the reasonable expectation that it would be protected.
People who may now have to monitor their accounts, watch for suspicious communications, or worry about the misuse of their information.
Most had nothing to do with the interaction that reportedly enabled the attacker to gain access.
They didn't respond to the impersonator.
They didn't disclose the credentials.
They didn't authorize the export.
Yet they may still face the consequences.
That's why I believe this conversation is about more than authentication technology.
It's about responsibility.
When organizations collect and maintain sensitive information, they assume an obligation to protect it.
And fulfilling that obligation requires more than checking whether someone has the right password.
It requires thoughtful decisions about identity, access, authorization, and the legitimacy of the parties involved.
Trust is not merely a cybersecurity feature. It's a responsibility we owe to the people whose information we hold.
Two AUTHs. One Fundamental Principle.
The Marathon Health incident illustrates why we must challenge some long-standing assumptions about digital security.
A valid credential doesn't necessarily mean the person presenting it is legitimate.
A successful login doesn't necessarily mean every subsequent action should be permitted.
And a request for authentication doesn't automatically mean the person or service making that request can be trusted.
These are three different problems, but they share a common thread.
Trust cannot be based solely on possession, appearance, or assumptions.
Authentication must establish identity.
Authorization must determine what that identity is permitted to do.
Mutual Authentication must help ensure that both parties in the authentication exchange are legitimate.
And appropriate controls must continue to protect sensitive information after the initial login.
We cannot say with certainty that any one of these measures would have prevented the Marathon Health incident. The publicly reported facts do not support that conclusion.
But we can say that the incident raises important questions about how organizations establish and enforce trust.
And those questions deserve serious answers.
For too long, we've concentrated on getting better at asking people to prove who they are.
Now we must become equally serious about verifying who is asking, what access is justified, and what actions should be allowed.
Because a credential may open a door.
But it cannot, by itself, tell us who is walking through it.
And even when someone has legitimately entered the building, that doesn't mean they should have the keys to every room.
One AUTH is not enough™.
And neither is one-sided trust.
Trust Starts Here™.