THE EMPLOYEE DIDN’T BREACH THE COMPANY.

THE ACCESS WAS NEVER REMOVED.

A Cybersecurity Case Study on Identity, Access, Zero Trust, and IT/OT Security

By SOLOMON ODUTAYO

The employee didn't breach the company.

The access was never removed.

That distinction can completely change how we understand a cybersecurity incident.

An employee leaves an organization.

Human Resources completes the separation.

The employee returns company property and moves on.

But somewhere inside the organization's identity environment, an important security control fails.

The account remains active.

The credentials remain valid.

Remote access remains available.

Then, 23 days later, at 2:13 a.m., that identity is used to connect to the corporate environment.

The former employee did not breach the company.

The organization failed to remove the access.

And that raises a more important cybersecurity question:

Why was the door still open?

🔵 THE INCIDENT BEGINS AT 2:13 A.M.

It is 2:13 a.m. inside a modern enterprise Security Operations Center.

Most of the building is quiet.

The SOC is still operating.

Security dashboards are monitoring authentication activity, VPN connections, endpoints, and network traffic.

Then an alert appears:

UNUSUAL VPN AUTHENTICATION

A senior SOC analyst notices the activity.

The authentication does not match the user's normal pattern.

Another cybersecurity analyst, Solomon, is asked to investigate.

At first, it looks like a routine identity investigation.

Was the user traveling?

Was there an unusual login?

Was the account compromised?

Was the VPN connection legitimate?

The investigation begins with the identity.

And that is where the first major problem appears.

🔴 THE IDENTITY WAS SUPPOSED TO BE DISABLED

The account belongs to Michael Grant, a former employee.

His identity record shows:

Employment Status: Terminated

Account Status: Enabled

VPN Access: Active

Michael left the company 23 days earlier.

The security team now has an uncomfortable question:

Why does a former employee still have an active corporate identity?

This is not simply a password problem.

It is an identity lifecycle problem.

When an employee leaves an organization, the offboarding process should not end with HR.

The termination event needs to flow through the organization's identity and access management processes.

Depending on the environment, that may include:

Disabling the user account
Revoking active sessions
Removing VPN access
Removing application access
Removing privileged permissions
Reviewing group memberships
Revoking authentication tokens and sessions
Recovering company devices
Reviewing associated service or shared accounts
Confirming that the offboarding process actually completed

In this scenario, HR completed its portion of the separation.

But the identity workflow did not successfully disable the account.

The employee was gone.

The identity was not.

🟠 THEN THE INVESTIGATION FINDS ANOTHER PROBLEM

The security team reviews the identity history.

The password has not been changed since before Michael's departure.

Now there is another concern.

If the account is still active and the credential remains valid, unauthorized use becomes possible.

But the security team does not immediately assume who used the credential.

That distinction is important.

A professional security investigation should separate:

WHAT WE KNOW

The former employee's account remained enabled.

The account retained VPN access.

The account was successfully used.

WHAT WE DO NOT YET KNOW

Who actually used the credential?

How was the credential obtained?

Was the credential exposed somewhere else?

Was the account compromised before the activity occurred?

Those questions require evidence.

The former employee's identity appearing in the logs does not automatically mean the former employee was responsible for the activity.

🔵 THE NETWORK PATH CHANGES THE SEVERITY

The security team continues following the activity.

The account connected to an engineering workstation:

ENG-WKS-17

That workstation has access to engineering resources.

The investigation continues.

Then something more concerning appears.

There is communication with an:

OT JUMP SERVER

At this point, the incident has moved beyond a simple identity-management issue.

But the team does not immediately declare the production environment compromised.

That would go beyond the evidence.

What they know is that the identity reached an access point associated with the organization's operational technology environment.

The investigation now follows a path:

IDENTITY

↓

VPN

↓

ENGINEERING WORKSTATION

↓

ENGINEERING NETWORK

↓

OT JUMP SERVER

This is where identity security, endpoint security, network security, and OT security intersect.

🔴 WHAT HAPPENED AT THE OT BOUNDARY?

The OT security engineer reviews the event.

The logs show:

AUTHENTICATION SUCCESSFUL

SOURCE: ENGINEERING ACCOUNT

DESTINATION: OT JUMP SERVER

The team investigates further.

The session authenticated.

The environment was queried.

Engineering resources were enumerated.

However, there is no confirmed evidence in this scenario that a production controller was accessed.

That distinction matters.

There is a major difference between:

Attempted or observed access

and

Confirmed compromise.

The security team has enough evidence to contain the activity.

So they act.

CONTAINMENT ACTIONS

ACCOUNT DISABLED

VPN SESSION TERMINATED

ENDPOINT ISOLATED

REMOTE ACCESS BLOCKED

OT SESSION ISOLATED

RELEVANT LOGS PRESERVED

The immediate risk is contained.

🟣 THEN COMES THE HUMAN CONVERSATION

The security team contacts Michael.

They ask:

"Did you attempt to connect to the company VPN tonight?"

Michael says no.

He has not worked for the organization since leaving.

The team asks whether he reused his former company password somewhere else.

He is unsure.

This conversation reinforces an important principle:

A compromised identity does not automatically identify the person responsible for the activity.

The investigation must follow evidence.

The security team needs to determine:

Who used the credential?
How was the credential obtained?
Was it exposed somewhere else?
Was the account compromised?
Were other accounts affected?
What systems were accessed?
What information was viewed or modified?
Was persistence established?
Did activity reach critical OT assets?

The identity is part of the evidence trail.

It is not automatically proof of the former employee's involvement.

🔥 THE REAL PROBLEM WAS BIGGER THAN ONE ACCOUNT

After containment, the team reviews the incident timeline.

The root cause becomes clearer.

It was not one isolated failure.

It was a chain.

THE CHAIN

The employee left.

↓

The identity remained active.

↓

The credentials remained valid.

↓

Remote access remained available.

↓

The identity reached an engineering endpoint.

↓

The network path allowed communication toward an OT access point.

The incident demonstrates something important:

Cybersecurity failures often happen because several controls fail to work together.

🔵 OFFBOARDING IS A CYBERSECURITY CONTROL

Employee offboarding is sometimes treated as an HR process.

From a cybersecurity perspective, it is much more than that.

Offboarding changes authorization.

When an employee leaves, the organization must ensure that their digital access changes accordingly.

A strong offboarding process should establish clear ownership between:

HR → IT → IAM → Security → Application Owners → System Owners

But ownership alone is not enough.

There must also be verification.

It is not enough for HR to say:

"The employee has been terminated."

The organization should be able to verify:

"The employee's digital access has been removed."

That difference can become the difference between a completed offboarding process and a security exposure.

🛡️ ZERO TRUST STARTS WITH IDENTITY

Zero Trust is often discussed in terms of network architecture, segmentation, device posture, and continuous verification.

But identity remains central.

Security teams should continually ask:

Who is this user?

Should this identity still have access?

What are they trying to access?

From what device?

From what location?

Under what conditions?

Does this activity make sense for this identity?

In this scenario, the first question should have been answered before the VPN connection occurred:

Should this identity still be active?

The answer was no.

That is why identity lifecycle management is a critical part of a Zero Trust approach.

🏭 IT/OT SECURITY ADDS ANOTHER LAYER

The scenario also demonstrates why the boundary between corporate IT and operational technology deserves careful attention.

A corporate identity reaching an engineering workstation is one concern.

That identity communicating with an OT jump server introduces another layer of risk.

Organizations operating manufacturing environments, utilities, healthcare systems, transportation systems, and other operational technology environments need to understand how identities and access paths move between IT and OT.

Network segmentation is important.

But segmentation should not become an assumption that:

"The OT network is isolated, so nothing can happen."

A better question is:

"What paths actually exist between these environments, and who can use them?"

Security teams should understand those paths before an incident occurs.

🧩 WHAT COULD HAVE PREVENTED THIS?

Several controls could reduce the likelihood or impact of a scenario like this.

1. Automated Identity Deprovisioning

Employee termination should trigger an identity workflow that disables access promptly.

Where possible, this should be automated.

2. Offboarding Verification

Automation should not be treated as proof of completion.

Organizations should verify that the account was actually disabled.

Failed workflows should create an exception that someone owns and resolves.

3. VPN Access Review

Remote access should be tied to current employment status and business need.

A terminated employee should not retain active VPN access.

4. Periodic Access Reviews

Organizations should periodically review:

User accounts
Privileged accounts
Group memberships
Remote access
Application permissions
High-risk system access

5. Strong Authentication

Strong authentication, including phishing-resistant MFA where appropriate, can reduce the impact of stolen credentials.

But MFA does not eliminate the need for proper identity lifecycle management.

An account belonging to someone who left the organization should still be disabled.

6. Network Segmentation

Engineering and OT environments should have carefully controlled access paths.

The objective is not simply to build a wall.

The objective is to understand and control:

Who can cross the boundary?

From where?

To what system?

Under what conditions?

7. Security Monitoring

Security monitoring should identify unusual activity such as:

Former or inactive identities attempting authentication
Unusual VPN activity
Authentication from unexpected locations
Unexpected devices
Engineering workstation connections
OT jump-server authentication
Unusual resource enumeration
Abnormal identity behavior

8. Incident Response

When suspicious activity is confirmed, organizations need a clear response process.

A response may include:

DISABLE → TERMINATE → ISOLATE → BLOCK → PRESERVE → INVESTIGATE → REMEDIATE

The exact response should depend on the organization's environment and incident-response procedures.

⚠️ THE BIGGER LESSON

Cybersecurity conversations often focus on sophisticated attackers.

Zero-day vulnerabilities.

Ransomware.

Advanced persistent threats.

Nation-state activity.

Highly skilled adversaries.

Those threats are real.

But security failures can also begin with something much simpler:

An account nobody disabled.

A privilege nobody reviewed.

A connection nobody questioned.

That is why identity security matters.

An attacker does not always need to break through the strongest part of the environment.

Sometimes the attacker finds something that was unintentionally left open.

🔍 CYBERSECURITY IS ABOUT FINDING THE GAP

The most important lesson from this scenario is not simply that organizations need more alerts.

They need to understand how their security controls work together.

An employee leaves.

HR records the separation.

IAM should disable the identity.

VPN access should be revoked.

Applications should remove authorization.

Endpoints should no longer trust the identity.

Network controls should limit unnecessary movement.

OT systems should have additional protection.

Security monitoring should detect activity that violates those expectations.

When one control fails, other controls should help limit the impact.

That is defense in depth.

💡 THE QUESTION SECURITY TEAMS SHOULD ASK

Instead of asking only:

"How do we stop attackers?"

We should also ask:

"What access exists today that should no longer exist?"

That question can lead security teams toward:

Better identity governance.

Better access reviews.

Better offboarding.

Better monitoring.

Better segmentation.

Better incident response.

And ultimately:

Better security.

FINAL THOUGHT

The former employee did not breach the company.

The organization failed to remove the access when the employee left.

That distinction matters.

Because cybersecurity is not only about identifying attackers.

It is also about identifying weaknesses in our own processes before someone else discovers them.

An account that should have been disabled can become an entry point.

A privilege that should have been removed can become an opportunity.

A connection that should have been blocked can become a path.

So the question is not only:

"How did the attacker get in?"

Sometimes the better question is:

"Why was the door still open?"

Cybersecurity is not only about stopping the attacker.

It is about finding the gap before the attacker finds it.

ABOUT THE AUTHOR

SOLOMON ODUTAYO

Master, Cybersecurity and Information Assurance

Master, Business Administration — Information Technology Management

Bachelor's, Information Technology

Associate, Computer Science

Diploma, Information Technology Security Administration

Solomon Odutayo is a cybersecurity professional with a background spanning cybersecurity, information technology, security, risk, compliance, and technology management.

His professional interests include Cybersecurity, GRC, Identity and Access Management, Risk Management, Zero Trust, Threat Detection, IT/OT Security, Security Awareness, and Incident Response.

This article is presented as a realistic enterprise cybersecurity case study for educational and professional discussion. The names, events, systems, and specific details are fictionalized and should not be interpreted as describing a specific real organization or individual.

CYBERSECURITY FOCUS

Contents