"The Door Worked Perfectly. That Was the Problem." represented by a premium conceptual technology graphic on a reflective white background illustrating identity threshold containment. A sequence of sapphire glass archways acts as an authentication framework. Valid green data streams enter from the right, but a compromised session transforms into a volatile orange and purple electrical threat inside the foremost arch. This volatility is trapped by an integrated vertical titanium shutter emitting a vibrant light-blue containment line, while parallel data paths pass safely through adjacent arches as calm, structured blue streams embedded with glowing binary numbers on the left."The Door Worked Perfectly. That Was the Problem." represented by a premium conceptual technology graphic on a reflective white background illustrating identity threshold containment. A sequence of sapphire glass archways acts as an authentication framework. Valid green data streams enter from the right, but a compromised session transforms into a volatile orange and purple electrical threat inside the foremost arch. This volatility is trapped by an integrated vertical titanium shutter emitting a vibrant light-blue containment line, while parallel data paths pass safely through adjacent arches as calm, structured blue streams embedded with glowing binary numbers on the left.
S10 Group Article series · The operational attack realities

The Door Worked Perfectly.
That Was the Problem.

Modern attacks do not always break access controls.
Sometimes they use valid access exactly as designed.
Article #9
Published: 25 September 2026
By Stan van Gemert | S10 Group
By Stan van Gemert
When attacks move series

Executive summary

The previous publication, Why Mature Security Stacks Still Fail Under Pressure, showed that sophisticated detection and monitoring can still leave incident teams without a safe, authorised way to interrupt an attack. A mature stack becomes operationally useful only when a credible signal can trigger a proportionate action before damage spreads.

This article follows that gap into identity and access. The username may be recognised, the second factor approved and the session opened exactly as designed, while the behaviour behind that session is already becoming harmful. The problem is no longer whether the door opened correctly, but what the approved session may still be allowed to reach and do.

Identity assurance remains essential, but authentication cannot establish intent on its own. Once valid access is used maliciously, your teams need the authority and capability to interrupt the behaviour, restrict the path and preserve the operations that can still continue safely.

The next publication, When Trusted Systems Become the Attack Path, widens the lens from one approved session to the systems, supplier connections and administrative routes around it. It examines how pathways created for legitimate operations can carry an incident further, and what your organisation must be able to narrow or disconnect before that pathway becomes a wider operational problem.

The illusion of legitimate permission

The login did not fail. The username was recognised. The password was accepted. The second factor was approved. The session opened. The system did exactly what it had been designed to do: it let a trusted identity in.

There was no broken lock, forced entry, or obvious perimeter failure in that moment that would make the incident easy to explain on the first call. The door worked perfectly. That was the problem.

The question was no longer whether the credentials were valid, but whether the behaviour behind that session was legitimate and safe to continue. An attacker may not need to breach the perimeter once it has been persuaded to welcome them. The incident can begin with permission rather than a blocked attempt. The attacker did not defeat the door. They persuaded the door that they belonged.

VALID IS NOT SAFE
A valid login proves that the door opened.
It does not prove that the behaviour behind the session should be allowed to continue.

When permission becomes the attack path

For years, security programmes have concentrated on entry: keeping the wrong people out, verifying users, strengthening passwords and adding multi-factor authentication. That work remains essential, but it does not solve the problem that appears after access has been granted.

A valid login can create a dangerous illusion by making the session resemble an employee, contractor, supplier or privileged operator carrying out normal work. The access log records success, the workflow shows approval and the security stack sees an identity that has already passed authentication.

The initial business consequence can be subtle because nothing looks like an intruder. The attacker is using permissions, approvals, tokens and workflows that already exist inside your environment.

This article is therefore not a technical argument about passwords or multi-factor authentication. This article examines what happens when a system that confirms identity is asked to prove something it was never designed to establish: intent.

Identity can tell you who appears to be acting. It cannot always tell you whether the action should still be allowed to continue.
WHEN APPROVED ACCESS OPENED THE PATH
Uber’s 2022 security update illustrates the difference between access approval and operational control. Uber said an external contractor’s account had been compromised. The attacker attempted to log in, two-factor approval requests were initially unsuccessful, and eventually one request was accepted. The environment was then dealing with a session that appeared legitimate enough to open further doors.

MGM Resorts’ 2023 disclosure shows the business consequence at enterprise scale. MGM said it shut down certain systems to mitigate risk after a cybersecurity issue and later estimated an approximately $100 million negative impact to Adjusted Property EBITDAR for affected operations. The executive lesson is not that one identity control caused the entire incident, but that approved access can create operational decisions far beyond the identity system itself.

Neither case supports a claim that multi-factor authentication failed as a technology or that one technical action would have prevented every consequence. But together, they show why your organisation needs a way to restrict what an approved session can still reach and do once its behaviour becomes unsafe.

- Approval establishes access; it does not establish operational control.
- A valid session can become an unsafe path.
- The decisive question is whether authorised teams can interrupt harmful behaviour before it becomes consequence.
‍
View more details chevron A white downward-facing V-shaped chevron on a transparent background.
View more details
Close more details
IDENTITY IS NOT INTENT
Identity can confirm who appears to be acting.
It cannot always confirm whether the action is safe, expected or still under control.

Why approved activity is so hard to interrupt

Harmful behaviour is hardest to interrupt when it remains inside a legitimate process. A help desk resets a credential, a contractor signs in from a familiar device, a privileged user opens a dashboard or a service account reaches a system it has used before. None of those actions is inherently malicious.

Each action may have a reasonable explanation and sit inside a workflow your organisation deliberately created so that people and services could work efficiently. The executive dilemma begins when the same route can support legitimate work and malicious activity.

If your security team interrupts every unusual authorised action, the business may stop itself. If it waits until malicious intent is proven beyond doubt, the attacker may use that delay to expand access, stage data, disable safeguards or prepare the next move. The issue therefore extends beyond detection to authority. Who may stop a valid session or block a privileged action before everyone agrees that it is malicious? Which behaviour is serious enough to interrupt while the identity still appears legitimate?

Attackers benefit from the hesitation between “authorised” and “safe”. Your organisation can see the immediate cost of interrupting a familiar workflow long before it can measure the cost of waiting.

THE GREEN IDENTITY SIGNAL IS NOT ENOUGH
The system may recognise the user, device or session.
Your incident team still needs to decide whether the behaviour should continue.

What valid access obscures

Valid access obscures what is happening before it causes disruption.

Your incident team can no longer rely on the old distinction between outside and inside. The attacker is operating through permission, so the first visible signs may resemble ordinary work rather than intrusion. The response also slows because every interruption has a business cost. Disabling an account may block a critical team, closing a remote route may stop legitimate support and freezing a privileged action may delay recovery. Waiting too long gives the attacker more time to spread, stage data or disable safeguards.

As the incident develops, colleagues begin asking whether the administrator was genuine, whether the supplier session remained legitimate and which entries in the audit trail represent business activity rather than attacker activity.

The result is a loss of confidence in your organisation’s ability to distinguish authorised work from malicious use of the same systems.

Identity confirmation is not operational control when an authorised session can continue to behave maliciously.

The executive decision

Every available choice carries risk. If your team treats every valid login as legitimate until proven otherwise, the attacker gains time. If it treats every unusual action as hostile, the business may create its own disruption. The decision sits between those two risks.

That choice should not be improvised during the incident.

Your executive team should define in advance which behaviours may continue, which require immediate interruption and who has authority to act while intent remains uncertain. Those boundaries should cover privileged actions, remote access, data movement, administrative tools and critical systems, including the evidence threshold that is sufficient for containment.

Identity security becomes an operational resilience question at that point. Proving who appears to be acting is only the first control; the response must also govern what that identity may continue to do after its behaviour becomes unsafe.

When a valid session starts behaving dangerously, who has authority to interrupt it before everyone can prove that the user or session is no longer legitimate?‍

Containment must follow behaviour

Containment changes the outcome when valid access starts producing harmful behaviour. Prevention seeks to stop entry, detection identifies suspicious activity and identity controls verify access. All three matter. Once an authorised session is being used harmfully, however, your organisation also needs a practical way to interrupt that behaviour before it creates wider consequence.

Our approach begins with what the session is actually doing. We do not ask only whether the login was valid; we focus on whether authorised teams can interrupt harmful activity after access has been granted.

Ransomware Containment is our platform. Server Intrusion Protection and Virtual Server Protection are additional features running on it. Together, these capabilities can help authorised teams interrupt malicious behaviour after entry, contain ransomware encryption and protect critical server and virtual infrastructure while investigation continues.

Containment must therefore follow behaviour as well as identity. An attacker may arrive through a valid door, but your team still needs the ability to limit what that access can reach and do.

CONTAINMENT FOLLOWS BEHAVIOUR
An attacker may arrive through a valid identity.
Control depends on whether harmful behaviour can still be interrupted before permission becomes consequence.

The door is only the beginning

The next incident involving valid access may not announce itself as a breach. It may begin with a password that works, a second factor that is approved, a session that looks normal, an administrator action that appears routine or a supplier path that has been used a thousand times before.

The first report may accurately state that the login succeeded, but that statement will be incomplete. A successful login is evidence that the access control worked, not that the subsequent behaviour was legitimate. The resilience question is whether your team can interrupt an authorised path once its use becomes unsafe.

The attacker did not break in. They logged in.

The door worked perfectly. That was the problem.

Run a focused ransomware resilience assessment

In a controlled sandbox, compare how the same file-encryption scenarios behave with your existing security controls active, first without Ransomware Containment and then with it.

During the assessment session, we can also walk your team through the wider containment layer. The live assessment focuses on controlled ransomware file-encryption scenarios. It does not directly test identity misuse, lateral movement or data exfiltration. But those questions can still be addressed in the same conversation.

‍
Alongside the assessment results, we can explain how our platform and its additional Server Intrusion Protection and Virtual Server Protection features, helps detect and interrupt lateral movement, reduce the risk of data theft, protect remote server access and defend virtual environments such as VMware and Hyper-V. That makes the session useful not only as a ransomware-containment test, but also as a practical discussion about what your organisation can still control when identity, privilege and infrastructure trust come under pressure.

The next horizon

This article examined why valid access cannot be treated as proof of safe behaviour. The next publication widens the lens from the session to the systems and operational relationships around it.

When Trusted Systems Become the Attack Path explores how approved platforms, supplier connections and administrative routes can extend an incident, and why resilience depends on narrowing or disconnecting an unsafe pathway while preserving the operations that can still continue safely.

Hear first when a new S10 Group release is published

Would you like to receive a short note when S10 Group publishes a new article or newsletter?

Leave your name and email address below. We will send a short update when a new release is available, with a brief summary and a direct link to the publication.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Coming soon

Monday 28 September, Resilience-series #4: "When Trusted Systems Become the Attack Path"

Wednesday 30 September, Leadership-series #4: "Trust Often Breaks Before Systems Fail"

Further readings