Onboarding is a process with an owner, a checklist and a deadline, because a new joiner who cannot work complains immediately. Offboarding has none of those things, because a departed employee whose access still works complains to nobody. That asymmetry quietly produces the largest population of unmonitored credentials in most organisations.
Security Researcher • Penetration Tester
Tarun Jaswani is an independent security researcher and penetration tester with over five years in offensive security, 100+ accepted vulnerability reports, and Hall of Fame recognition from Google, Zoho, TripAdvisor and Adafruit. He writes about security for the people who have to build and defend real systems.
Ask any organisation how many active accounts belong to people who no longer work there. Very few can answer. That is not because they are careless. It is because the systems that grant access and the systems that record employment are usually different systems, connected by a human being remembering to do something on a day when several other things were also happening. Onboarding self-corrects — a new joiner without access raises a ticket within the hour. Offboarding does not, because nothing breaks and nobody notices.
https://about.me/tarun_jaswani
An account belonging to someone who left is not automatically an insider threat. Most departures are entirely amicable and most former employees never think about the account again. It is a security problem for a different reason: it is a live credential that nobody owns, nobody monitors and nobody would miss.
https://dev.to/tarun_jaswani_e9a4c1020df/why-identity-is-the-new-security-perimeter-29c6
Why This Is Structurally Hard.
• Access accumulates from many sources. Directory accounts, SaaS applications bought by individual teams, cloud consoles, code repositories, VPN, database credentials, third-party dashboards. HR knows about the person; nobody has a complete list of what the person could reach.
• Shadow SaaS is invisible to the offboarding process. A team that signed up for a tool with a corporate card never told IT it exists, so it is not on the checklist that never existed.
• Shared and service accounts have no individual to deprovision. When someone leaves knowing the shared password, the credential is compromised and rotating it breaks things nobody has documented.
• Contractors and partners have access with no employment record to trigger a review at all.
• Personal devices retain cached sessions and tokens that survive a password reset, because revoking a session is a different action from changing a credential.
The asymmetry in one line
Onboarding failures are noisy and self-correcting. Offboarding failures are silent and permanent. Any process relying on someone remembering will therefore fail in exactly one direction, and it is the direction that matters.
The Related Problem: Access That Accumulates.
Departure is only the visible half. The larger volume issue is that access grows over a career and almost never shrinks. Someone joins support, moves to operations, then to engineering, and at each step gains what the new role needs while retaining what the old one had. After several years they hold a combination of permissions nobody would ever deliberately grant to one person.
This is where a compromised ordinary account becomes serious. An attacker phishing a long-tenured employee frequently inherits more than the current role implies — not because privileges were escalated, but because they were never removed.
https://dev.to/tarun_jaswani_e9a4c1020df/attackers-do-not-break-your-password-anymore-they-take-over-your-account-recovery-506l
What Actually Works.
- Build the application inventory first. You cannot deprovision from systems you do not know exist. Reconcile expense records and single sign-on logs against your official list — the gap is your shadow SaaS.
- Make identity the control point. Where an application supports single sign-on, use it, so that disabling one account genuinely removes access rather than removing one of several routes in.
- Terminate sessions and revoke tokens on departure, not just passwords. An active session or a personal access token survives a password change, and both are commonly missed.
- Trigger deprovisioning from the employment record automatically. Any process depending on someone remembering will eventually not be remembered.
- Review access on role change, not only on exit. This is where the accumulation problem is actually solved, and almost nobody does it.
- Run periodic recertification. Managers confirm, on a schedule, that each person still needs what they hold. Tedious, unpopular, and the only reliable way to catch what the automated triggers missed.
- Treat shared and service accounts as inventory with owners. Every one should have a named owner, a documented purpose and a rotation schedule, or it should not exist. https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-is-more-than-fixing-vulnerabilities-32jl https://github.com/tarunjaswani/Vulnerabilities-notes The Test That Tells You Where You Stand. Pick someone who left six months ago and try to establish, concretely, whether every access they held has been removed. Not whether the directory account is disabled — whether the code repository, the cloud console, the analytics tool, the customer support platform, the shared drive, the third-party dashboard and the VPN all reflect that departure. Two things usually emerge. Something is still active, and more importantly, nobody can produce a definitive list of what to check. The second discovery is the more valuable of the two, because it is the actual finding: the organisation cannot answer the question, which means it cannot answer it for anyone else either. https://dev.to/tarun_jaswani_e9a4c1020df/lessons-every-cybersecurity-engineer-learns-from-real-world-web-applications-4pn1 Why This Matters More Than It Used To. When applications lived inside a corporate network, removing network access removed most access as a side effect. That containment is gone. Applications are reachable from anywhere, authentication is the only barrier, and an account that still works is a fully functional way in from any coffee shop in the world. Which makes the identity layer the actual perimeter, and orphaned accounts holes in it. They are also the least likely to be detected, because nobody is monitoring an account whose owner nobody remembers — there is no baseline to deviate from and no person to ask whether the activity was theirs. https://dev.to/tarun_jaswani_e9a4c1020df/why-web2-security-still-matters-in-an-ai-driven-world-16ii https://github.com/tarunjaswani/bounty-targets-data https://github.com/tarunjaswani/awesome-cybersec Where to Start If This Is All New. • List every application holding company data. Include the ones bought by individual teams. This is the foundation for everything else. • Reconcile active accounts against current employees in the three or four most sensitive systems. Expect surprises. • Disable rather than delete what you find, so you can restore quickly if something turns out to be in use. • Write the offboarding checklist and attach it to the employment record so it fires automatically. • Schedule the first access recertification and treat the completion rate itself as a security metric. https://www.linkedin.com/in/tarun-jaswani-a85b55401/ https://github.com/tarunjaswani Onboarding is a process because failing it is loud. Offboarding is an afterthought because failing it is silent, and the result is a population of live credentials nobody owns, monitors or would miss. Inventory what exists, drive deprovisioning from the employment record rather than from memory, revoke sessions as well as passwords, and review access when roles change rather than only when people leave. — Tarun Jaswani https://x.com/TJaswani7857 https://dev.to/tarun_jaswani_e9a4c1020df
TAGS
Top comments (0)