Orphan Accounts After the Merger

They solve a different problem.

• The firewall and VPN are perimeter and authentication controls. They stop unauthenticated outsiders. A leaver with an active account and an enrolled token satisfies both and is, from the network's point of view, a legitimate user.
• The missing layer is authorisation and identity lifecycle management: deciding who should have access, granting the minimum, and removing it when the relationship ends. No perimeter device can remove an entitlement inside the directory.
• Least privilege makes the argument void: an account with no valid business need should not exist at all, so there is nothing for a compensating control to protect.

What the exposure actually is

• 61 ex-employees with live credentials and inside knowledge of claims processes; insurance data includes health and financial details, so the regulatory and notification exposure is high.
• 340 unjustified administrative accounts on the claims platform represent a path to full platform compromise from any one compromised endpoint.
• Accounts with no HR match also mean the organisation cannot answer 'who has access to this system' - which is the question auditors, regulators and incident responders will ask first.

Governing controls

Access control policy, identity management tied to an authoritative HR source, allocation and removal of access rights on movement and exit, timely removal of post-employment access, and privileged access management. Removal on exit is an obligation that belongs to the employing entity, not to the network team.

Deferring to 2027 is not risk-based: it is a decision to keep 61 known-bad credentials live for two more years.

Why a shared administrative login is a control failure

• Identity: it breaks the one-identity-per-person principle. No one can say which human performed an action.
• Accountability: logs become worthless for investigation and for HR action. If misuse is detected, the investigation cannot attribute it, so the incident response and disciplinary paths both fail.
• Authentication secrecy: the password lives in a wiki readable by 60 people. That is not a stored secret, it is public within a group, and it cannot be rotated reliably because nobody knows who depends on it.
• Revocation: you cannot remove one person's access without locking out 21 colleagues, so in practice nobody removes it.
• Privilege: 22 people with standing administrative rights on a claims platform is almost certainly not least privilege; most will need read or workflow roles only.

What replaces it

• Named individual accounts for each of the 22, with justified roles mapped to what they actually do.
• A privileged access management vault: credentials checked out on approval, time-boxed, with session recording and full logging.
• Just-in-time elevation instead of standing admin, plus strong authentication on elevation.
• A sealed break-glass account for emergencies, with alerting on any use and periodic credential rotation.
• Immediately: rotate the shared password, remove the wiki page, and review logs of the shared account for out-of-hours or unusual activity - the account may already have been used by someone who should not have it.

Judgement point

The programme will propose adding MFA to the shared account. That improves authentication but leaves attribution, revocation and least privilege untouched.

What could go wrong if you act too fast

Bulk-disabling 1,180 accounts on day one will very likely break production. Some 'orphans' will be service accounts, integration accounts, scheduled jobs or vendor support accounts that were never linked to HR. An outage in claims handling during a merger is a serious availability incident and will destroy the credibility of the whole programme.

Sequence

1. Classify before disabling: human, service, shared or vendor. Require the system owner to attest to each account's purpose.
2. Immediate actions that carry little availability risk: revoke the 61 verified leavers, rotate and remove the shared claimsadmin credential, and add enhanced monitoring on privileged accounts while cleanup continues.
3. Disable confirmed orphan human accounts in batches, with a rollback window, a named owner per batch and a support channel for the inevitable 'I can't log in' calls.
4. Fix the root cause: HR as the authoritative identity source, with automated joiner, mover and leaver events; one identity per person across the merged estate; documented exception process for service accounts with owners and expiry dates.
5. Establish the review cadence and record it: at least annual for all access, quarterly for privileged access, with reviewers who actually understand the entitlement.
6. Make cleanup a prerequisite of the 2027 migration, not a follow-up. Migrating uncleaned entitlements reproduces the problem on the new platform.

Reporting

Track accounts without an HR match trending to zero, percentage of access reviews completed on time, and time from HR exit to access removal. Report these monthly to the merger board until they are stable.