Every SFTP deployment has the same problem: SSH keys are permanent by default. They sit on servers and workstations for years. They accumulate across teams, contractors, and trading partners. Nobody has a complete inventory. And when a key is compromised, the blast radius is unknown because nobody knows everywhere it has been used.

This is not a configuration problem. It is a protocol design problem. SFTP was built for a world where static credentials were acceptable. That world ended.

The SSH Key Problem at Scale

In a typical enterprise SFTP deployment:

• Key rotation is manual and inconsistent. The SSH protocol has no built-in key expiration. Keys remain valid until someone actively removes or replaces them. In practice, rotation happens after incidents, during audits, or never.
• Key-to-person mapping degrades over time. Keys are generated on workstations, copied between servers, shared in tickets. Within a year, most organizations cannot definitively map which keys belong to which people or systems.
• Authorized_keys files accumulate entries. Old keys are rarely removed because nobody is confident they are no longer in use. The result is an ever-growing attack surface.
• Contractor and partner keys persist after relationships end. Deprovisioning requires knowing every server where a partner's key was installed — information that is rarely tracked comprehensively.

The fundamental issue is that SSH keys are identity-free credentials. Possessing the key is equivalent to being authorized. There is no additional identity verification, no expiration, and no centralized revocation.

Short-Lived Certificates: The Architecture

The alternative is short-lived certificates issued by a trusted certificate authority (CA) and bound to verified identities. Here is how this works:

Step 1: Identity Verification

The user authenticates through your enterprise identity provider (Azure AD, Okta, Google Workspace, or any OIDC/SAML provider). This establishes who they are through strong authentication — SSO with enforced MFA.

Step 2: Certificate Issuance

After identity verification, the system issues a short-lived client certificate:

• Certificate validity: 30 days default, 90 days maximum
• Identity binding: The certificate contains the verified user identity, organization, and device information
• Key generation: For maximum security, private keys are generated in hardware — TPM 2.0, macOS Secure Enclave, YubiKey PIV, or Windows Hello. Hardware-bound keys are non-exportable — they cannot be copied, shared, or stolen via filesystem access.

Step 3: Mutual TLS Authentication

File transfer operations use the issued certificate for mutual TLS (mTLS) authentication. Both the client and server present certificates, establishing bidirectional identity verification. Access tokens issued for mTLS sessions have a 15-minute lifetime — even shorter than standard sessions.

Step 4: Automated Lifecycle

Certificate renewal, revocation, and audit are automated:

• Renewal: Certificates approaching expiration are automatically renewed if the user's identity remains valid in the IdP
• Revocation: Certificates can be revoked instantly via admin action or automated policy (e.g., when a user is deactivated in the IdP). Revocation is checked at two layers: CRL from the CA and database status.
• Audit: Every certificate issuance, renewal, use, and revocation is logged as a structured audit event

Hardware-Backed Keys: Why They Matter

The weakest point in any certificate-based system is the private key. If private keys can be exported — copied from one machine to another — you have replicated the SSH key problem with extra steps.

Hardware-backed keys solve this:

With hardware-backed keys:

• Private keys are generated inside the hardware module and never leave it
• Keys cannot be copied, exported, or extracted even with root/administrator access
• Cryptographic operations happen inside the hardware — the key material is never in application memory
• Device loss or theft is managed through certificate revocation, not key rotation across servers

MnemoShare's Implementation

MnemoShare integrates certificate-based authentication with PKI infrastructure:

Certificate Authorities: Production-ready integration with Smallstep CA (JWT-based provisioning) and HashiCorp Vault PKI (supports Kubernetes, Token, and AppRole auth). Each organization can configure its own CA, enabling multi-tenant deployments with separate trust roots.

Device Approval Flow: When a user enrolls a new hardware key, the certificate enters "pending" status. An administrator must approve the device before it can be used for file operations. This prevents unauthorized certificate use even if someone gains access to the CA.

Enforceable Policy: Organizations can require hardware-backed mTLS for all file uploads and downloads. When enabled, every file operation requires a valid, approved hardware certificate. API keys for automation can be individually exempted.

Audit Trail: Every certificate lifecycle event — issuance, renewal, use, revocation — generates a structured audit event exportable to SIEM and WORM storage.

The Migration from SSH Keys

Replacing SSH keys with short-lived certificates is an incremental process:

1. Deploy a CA — Smallstep CA or HashiCorp Vault with MnemoShare's PKI integration
2. Enroll users — Users generate hardware-backed keys and submit CSRs through the enrollment flow
3. Approve devices — Administrators review and approve enrolled devices
4. Enable mTLS enforcement — Configure the policy to require hardware certificates for file operations
5. Decommission SFTP — As certificate-based access covers all transfer flows, decommission SFTP servers and remove SSH key infrastructure

The result: zero permanent credentials, identity verification at every access, hardware-bound keys that cannot be stolen via software, and a complete audit trail of every certificate event.

For a broader comparison of SFTP and modern file exchange, see our SFTP Replacement guide. To understand how this fits into the overall security architecture, visit our Security page.