One Badge, Two Years Inactive—and it Still Works
The Red Team doesn't enter the building through the main entrance. They enter using the badge of Thomas K.—an employee who left the company 26 months ago. The badge was never deactivated. The AD account was never locked. The VPN credentials were never revoked. The mailbox is still running. And the access authorization to the server room, which Thomas received back then for a project, still exists—quiet, unnoticed, and fully valid.
This isn't a manufactured scenario. It's a summarized pattern from dozens of real engagements. In almost every company we audit, we find active credentials from individuals who have long ceased to be part of the organization: former employees, completed internships, terminated contractor agreements, finalized projects. The accounts live on—because in most companies, offboarding is not a process, but a hope.
Orphaned access points are the most frequently overlooked vulnerability in enterprise security architecture. They require no exploit, no social engineering expertise, and no technical brilliance. They only require the knowledge that they exist—and the credentials to match.
Why Offboarding Systematically Fails
Offboarding sounds like an HR topic. In practice, it's an interface problem—and interface problems always fail when no clear ownership is defined. When an employee leaves the company, between five and fifteen different systems are affected, depending on company size. Each has a different owner, a different interface, and a different process rhythm.
- Termination contract
- Payroll settlement
- Employment references
- Deactivate HRIS entry
- Key return (physical)
AD Account Locking
Cloud SSO Revocation
VPN Credentials
SaaS Access
Shared Secrets
API Keys
Git Access
- Collect laptop
- Forward email
- Remote wipe device
- – if a ticket comes –
- – if someone asks –
The leak lies in the middle. HR completes the labor law process and returns the device. IT waits for a ticket. Who creates the ticket? Often, nobody. Or someone—but too late, incompletely, without knowing all the systems. Especially dangerous: Systems that no one actively has in mind. The VPN access set up for a specific project. The AWS IAM user with admin rights that the developer created themselves. The badge access to the server room that was expanded for a temporary task and then simply left active.
The most dangerous orphaned account isn't the one that was forgotten. It's the one that only one person knew about—and they just left the company.
The Full Attack Surface: Where Orphaned Access Lurks
Orphaned access is not just a badge problem. It is a systemic issue that runs through all layers of corporate infrastructure—from the front door to the production database. Every level has its own risks, its own management systems, and its own blind spots.
The Full Attack Chain: From Phantom Badge to Production System
In real-world engagements, orphaned access rarely leads to a single, isolated incident. It's the starting point of a chain—because every active identity opens further doors.
# Accounts not used for >90 days
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter * -Properties LastLogonDate, Enabled |
Where-Object { $_.Enabled -eq $true -and $_.LastLogonDate -lt $cutoff } |
Select-Object Name, SamAccountName, LastLogonDate |
Sort-Object LastLogonDate
→ Every hit is a potential phantom account
Why Orphaned Access is a Compliance Problem—Not Just a Security Issue
Identity Lifecycle Management is not a "best practice." For a growing number of companies, it is a legally binding obligation. Relevant frameworks address the topic explicitly—with different focuses, but a common consequence: failing to manage orphaned accounts is a violation of verifiable requirements.
| Framework | Requirement | Relevance for Offboarding | Status |
|---|---|---|---|
| NIS2 | Access control and identity management as explicit security measures (Art. 21) | Orphaned accounts are a direct violation of the minimum security level | Mandatory |
| ISO 27001 | A.9.2.6: Removal of access rights upon termination of employment | Explicit control requirement—auditable and certification-relevant | Mandatory |
| GDPR | Restrict data access to the necessary minimum (Data minimization, Art. 5) | Active access of former personnel to personal data is a GDPR violation | Mandatory |
| SOC 2 | CC6.2: Logical access provisioning and deprovisioning | Missing deprovisioning evidence leads to audit findings and endangers certification | Audit-Relevant |
| CER Directive | Physical and logical access control for critical entities | Orphaned physical badges in critical infrastructure are a direct compliance violation | Mandatory |
Identity Lifecycle Management: What a Functional Offboarding Process Must Deliver
The goal isn't just a better "Offboarding Checklist" document. The goal is an automated, cross-system deprovisioning process that requires no manual intervention—and verifiably documents what was revoked and when.
- HR System as Single Source of Truth: An employee's departure must be recorded in the HRIS and automatically trigger a deprovisioning workflow. No ticket, no manual step—the process starts itself. Tools like Workday, BambooHR, or SAP SuccessFactors offer such integrations.
- Identity Provider as the Central Lever: All systems must be provisioned via a single IdP (Entra ID, Okta, JumpCloud). A single deactivation in the IdP revokes all downstream access simultaneously—AD, SSO apps, VPN with AD auth. What doesn't run through SSO is a risk.
- ACS Integration into the Offboarding Workflow: Badge deactivation must not depend on a separate IT ticket. The Access Control System should be integrated into the offboarding workflow directly or via the IdP. For offline locks: define and monitor maximum sync intervals.
- Maintain API Key and Service Account Inventory: Every technical credential must be assigned to an owner—and that owner must be addressed in the offboarding process. Tools like HashiCorp Vault, AWS Secrets Manager, or GitHub Enterprise enable owner-based credential management.
- SaaS Discovery for Shadow IT: Tools like Nudge Security, Grip Security, or BetterCloud scan OAuth grants and SaaS access, making visible which services an employee had access to. Without this overview, full offboarding is impossible.
- Regular Access Reviews: Offboarding doesn't close gaps created by temporary access expansions. Quarterly access reviews of all privileged accounts—AD, Cloud IAM, ACS—uncover accounts that were never officially deactivated. The PowerShell query above is a good starting point.
- Monitoring for Inactive Account Usage: Any authentication with an account that hasn't been used for more than 30 days should trigger an alert. In SIEM systems (Splunk, Microsoft Sentinel, Elastic), this is a simple correlation rule—and one of the most effective.
- Physical Pentest with Phantom Badge Test: A structured audit that specifically attempts to gain access using the credentials of former employees provides empirical evidence of the actual state of the offboarding process. We perform this test as part of every Physical Security engagement.
A complete offboarding process revokes all access—physical and digital—within a maximum of 24 hours after contract end and verifiably documents every revocation. Anything longer or manual is a gap.
Conclusion: The Most Dangerous Attacker is the One You Fired Long Ago
Thomas K. left the company 26 months ago. He has no ill intentions; he isn't the attacker. But his badge, his AD account, and his API key still exist—and an attacker who knows or finds these credentials is Thomas K. to all affected systems.
Orphaned access points are not a side issue or a niche problem. They are the most likely source of successful access in almost every company that doesn't operate an automated Identity Lifecycle process. They are quiet, persistent, and entirely avoidable.
The question isn't "Do we have orphaned accounts?" The question is "How many—and who knows it besides us?"
How Many Active Access Points Does Your Company Still Have for People Long Gone?
We test phantom badges, orphaned AD accounts, and forgotten API keys—providing a complete breakdown of your Identity Lifecycle gaps.
Request Identity & Access Audit →