Every guide to SSH key sprawl gives the same first step: discover what you have. Run a scanner across your fleet, parse every authorized_keys file, build an inventory, assign owners, set expiry.

That advice is correct, and it solves roughly half the problem.

The other half is the keys you issued to organizations outside your network. The private half of those key pairs sits on a machine you have never seen, at a company whose offboarding process you do not control. No scanner reaches it. No inventory tool discovers it. And in most regulated organizations, that population is larger than the internal one.

What is SSH key sprawl?

SSH key sprawl is the accumulation of key pairs faster than an organization can track ownership, enforce expiry, or verify where each key is authorized.

The scale is well documented. Studies commonly cite enterprises averaging tens of thousands of SSH keys with the large majority unmanaged, and somewhere between 60 and 90 percent of organizations lacking a complete inventory of their active keys. Individual servers routinely carry between 50 and 200 authorized keys.

The mechanism is simple. SSH keys have no expiration date by default. A key provisioned in 2019 works exactly as well in 2026. Nothing in the protocol forces a review. Access persists until a human decides to remove it, and nobody is assigned to decide.

Why can't you inventory a partner's keys?

Because inventory works by looking at machines, and the machine is not yours.

When you set up file exchange with an outside organization, one of two things happens.

They connect to you. You create an account on your SFTP server and add their public key to its authorized_keys file. You can see this key. A scanner finds it. But you cannot see how many copies of the corresponding private key exist on their side, who has access to it, whether it is checked into a repository, or whether the person who set it up still works there.

You connect to them. Now the private key is on your infrastructure and the authorization lives on theirs. You can inventory your own key material, but you have no visibility into what it is authorized against, whether that authorization has been duplicated to other systems, or whether it was ever removed when the integration was retired.

In both cases you hold exactly one half of a fact, and the half you hold is the half that does not answer the question.

What actually happens when a vendor offboards someone

Consider the sequence, because it is entirely ordinary.

An analyst at your billing vendor sets up the SFTP connection in 2022. They generate a key pair on their laptop, send you the public half, and you add it. The connection works. Nobody thinks about it again.

In 2024 that analyst leaves. The vendor's offboarding checklist covers their email, their VPN, their badge, and their access to the vendor's own systems. It does not cover a key pair they generated on a laptop three years ago for a connection to your environment, because your environment is not on the vendor's asset list.

The laptop gets wiped or it does not. The key gets copied to a shared drive during a handoff or it does not. A new analyst inherits the integration and reuses the same key rather than requesting a new one, which is the path of least resistance and extremely common.

None of this is visible to you. Your side shows one authorized public key, unchanged since 2022, working normally. That is all your monitoring can tell you, and it is consistent with everything from perfect hygiene to a key sitting in a former employee's personal cloud backup.

Why rotation does not solve this

Rotation is the standard prescription and it is genuinely useful, but it addresses a narrower problem than people assume.

Rotating a partner key means coordinating with the partner: generating new material, exchanging it, updating both sides, and confirming the old key is removed. That last step is the one you cannot verify. You can remove the old public key from your server, which stops it working against you. You cannot confirm the old private key was destroyed on their side, and you have no way to know whether it was copied before you asked.

There is a second problem. Rotation is a coordination cost that scales with partner count. A hospital exchanging records with forty payers, labs, and referring groups is running forty separate negotiations on every rotation cycle. In practice this means rotation gets scheduled annually, then deferred, then quietly abandoned, which is why the audit finding is so consistent across organizations.

The most common questions an auditor asks about this are not answerable by rotation policy. They are:

• Which external parties currently hold credentials to your systems?
• When was each one last changed?
• Who at that organization can use it?
• What did each one access, and when?

A rotation schedule answers the second question if it is actually followed. It does not touch the other three.

What can you actually control?

Not the partner's key hygiene. The structure of the credential and the record of what it did.

Make the credential expire on its own. The reason a 2019 key still works is that nothing forces a decision. A credential with a built-in lifetime converts an indefinite grant into a recurring one. The former analyst's key stops working whether or not anyone remembered to remove it, and whether or not the vendor's offboarding was thorough.

Bind the credential to a verified person rather than an account. A shared service key produces log entries that identify the account, which tells you nothing about who acted. Identity-bound access means the log answers "who," not "which integration."

Instrument the exchange, not just the connection. Most SFTP logging records that a session occurred and a file moved. It does not produce a record you can hand to an auditor showing who accessed a specific file, when, and whether it changed afterward. Those are different artifacts, and only the second one survives being questioned.

Inventory the relationships, not the keys. You cannot enumerate your partners' key material. You can enumerate the partners and what each is authorized to reach. That list is finite, it is knowable, and almost nobody maintains it.

Does a file transfer platform solve SSH key sprawl?

Partly, and it is worth being precise about which part.

We do not manage your internal SSH keys. If the problem you are solving is thousands of keys across your own server fleet, CI/CD pipelines, and jump boxes, that is what PAM and certificate lifecycle management tools are for. We are not one of them and we do not compete with them.

What we do is remove the standing credential from the external exchange specifically. Partner access uses short-lived, identity-bound credentials rather than a permanent key pair, so there is no long-lived secret sitting on a machine you cannot see. When someone leaves the partner organization, their access ends because the credential was never indefinite. And every exchange produces a structured, append-only, tamper-evident audit event exported to storage you control, so "who accessed this file" is a query rather than a reconstruction.

That is a narrower claim than solving SSH key sprawl. It is the external half, which happens to be the half no scanner reaches.

More on ephemeral credentials and audit evidence. For healthcare specifically, HIPAA-compliant file sharing.

The short version

The discovery-first advice in every key management guide is sound for infrastructure you own. It quietly assumes you can see the machine holding the key.

For external file exchange you cannot, and no amount of scanning changes that. The question worth asking this quarter is not how many keys you have. It is how many organizations outside your network currently hold credentials to your systems, and whether any of those credentials would stop working on their own.

Request a demo

Sources

• NHI Management Group, SSH key sprawl exposes the limits of manual PKI governance
• Keyfactor, Solving the Problem of SSH Key Sprawl
• LinuxSecurity, SSH Key Sprawl on Linux: Unmanaged Access Threats and Cleanup Guide
• Encryption Consulting, SSH Key Management Compliance