By Yair Knijn · April 3, 2025

The SSH key that still works six months after the contractor left

A contractor wraps up a six-week SFTP integration. The manager files the offboarding ticket, IT disables the identity in Entra, and the CISO signs the attestation that access was removed. What nobody checks is the contractor's public key, still sitting in ~/.ssh/authorized_keys on the SFTP host. That host never asked Entra for permission to let anyone in, and it isn't going to start now.

The audit eventually disproves the assumption underneath the whole process: that disabling the directory identity closes every door that identity walked through. A CISO who treats the Entra account as the single source of truth has signed a claim one command will contradict.

Why disabling the Entra account does not revoke the SSH key

Key authentication is a local trust decision made on the host. When the contractor connects, the server checks the presented public key against the lines in authorized_keys for that Unix account, then verifies a signature from the matching private key. No call to Entra, no token, no group lookup. Disabling the Entra user locks them out of the portal and Microsoft 365 and does nothing to a file placed on a Linux box by hand.

NIST's IR 7966, the federal guidance on Secure Shell access management, calls this out directly: SSH was never built with key expiration, renewal, or automated validity checks, so keys persist until someone deliberately removes them. A key authorized in October still authenticates in April unless a human edited that file in between.

How keys accumulate: shared accounts, copied configs, no rotation

Orphaned keys are rarely one forgotten entry. The contractor's key usually lands in a shared functional account such as sftpuser or partner-feed, so disabling their personal account was never going to matter; they never logged in as themselves. Clone the host to staging and the authorized_keys file rides along. Copy a runbook into the next partner's onboarding and the same key gets pasted into a second home. Nothing here forces rotation. The patterns that routinely survive offboarding:

• Keys in shared service accounts, tied to no human identity in the directory
• Keys copied across staging, DR, and cloned hosts during ordinary operations
• Keys with an empty comment field, so you cannot tell whose they are or when they arrived
• Private keys still sitting on a contractor's laptop, which you do not control and cannot wipe

The offboarding checklist that never reaches the SFTP host

Most offboarding is HR-driven and identity-shaped. Disable the account, reclaim the laptop, remove from groups, done. The workflow assumes IAM is the chokepoint. SFTP hosts almost never make the list, because they were provisioned outside the directory and whoever added the key has since moved on. No field on that ticket says which hosts hold this person's keys, so the question never gets asked.

When the auditor wants proof that a departed contractor's access was actually removed, an honest answer means dumping every authorized_keys file across the fleet and matching fingerprints. Skip that and "we deprovisioned them" is a hope dressed up as a fact. One grep turns an attestation into a finding, and the gap can run months wide.

Bringing SSH keys under identity governance and rotation

The fix is to stop treating key files as static configuration and start treating them as access grants that belong to an identity with a lifecycle. Every authorized key should map to a named person or service, carry an issue and expiry date, and live in an inventory you can query rather than scattered across hosts. Offboarding then becomes a query against that inventory instead of a memory test. Short-lived keys or certificate-based auth retire the never-expiring file entirely, so an unrevoked credential expires on its own.

xEvolve runs SFTP inside a governed Environment where every key is bound to an identity with an expiry and a full audit trail. When a contractor leaves, their access ends where their identity ends, and the authorized_keys dump matches what you told the auditor. See how the security model ties key lifecycle to identity instead of leaving it on the filesystem.