Teleport and QCecuring solve SSH security from fundamentally different angles. Teleport replaces SSH keys entirely — it’s an infrastructure access platform that uses short-lived certificates, SSO integration, and a proxy architecture to eliminate static keys altogether. QCecuring’s SSH KLM takes the opposite approach — it manages the SSH keys you already have, providing discovery, rotation, ownership tracking, and compliance reporting for existing key-based infrastructure.
The choice depends on where you are in your SSH security journey: modernizing from scratch (Teleport) or governing what already exists (QCecuring).
Company Backgrounds
Teleport (Gravitational)
Teleport was created by Gravitational, founded in 2015 in Oakland, California. The product started as an SSH bastion/jump server replacement and evolved into a full infrastructure access platform covering SSH, Kubernetes, databases, Windows RDP, and internal web applications.
Key facts:
- Founded: 2015 (Gravitational), product launched ~2016
- GitHub: 20,200+ stars (open-source core)
- Funding: $110M+ (Bessemer Venture Partners, Kleiner Perkins)
- Architecture: Go-based, certificate authority built-in, proxy-based access
- Products: Teleport Community (open-source), Teleport Enterprise (self-hosted), Teleport Cloud (SaaS)
- Approach: Replace SSH keys with short-lived certificates + identity-based access
- Scope: SSH + Kubernetes + databases + Windows + web apps (unified access)
- 170+ integrations
Teleport’s philosophy: Static SSH keys are fundamentally insecure — they don’t expire, they get copied, they accumulate without governance. Instead of managing keys, eliminate them. Use your identity provider (Okta, Azure AD, GitHub) as the source of truth, issue short-lived SSH certificates (minutes to hours), and maintain a complete audit trail of every session.
QCecuring
QCecuring’s SSH Key Lifecycle Management (SSH KLM) product manages the SSH keys that already exist across your infrastructure — discovering them, tracking ownership, enforcing rotation policies, and providing compliance reporting.
Key facts:
- Products: SSH KLM (key discovery, rotation, compliance), CertSecure (CLM), CBOM
- Approach: Govern existing SSH keys + enable certificate-based SSH where possible
- Architecture: Spring Boot, single JAR, agent-based discovery
- Scope: SSH key management as part of broader cryptographic lifecycle
Fundamental Architecture Difference
This is the core distinction:
| Aspect | Teleport | QCecuring SSH KLM |
|---|---|---|
| Philosophy | Eliminate SSH keys entirely | Manage existing SSH keys |
| Authentication | SSO → short-lived certificates | Key-based (with rotation) |
| Key lifecycle | No keys to manage (certificates expire automatically) | Discovery, rotation, revocation, compliance |
| Infrastructure change | Requires Teleport agent on every server | Agent discovers existing keys non-disruptively |
| Migration effort | High (replace entire SSH access model) | Low (overlay on existing infrastructure) |
| Audit | Complete session recording + replay | Key usage tracking + compliance reports |
| Scope | SSH + K8s + DB + Windows + Web | SSH keys (+ TLS certs via CertSecure) |
Feature Comparison
SSH Access & Authentication
| Capability | Teleport | QCecuring SSH KLM |
|---|---|---|
| SSO-based SSH access | Yes (core feature) | No (manages keys, not access) |
| Short-lived SSH certificates | Yes (built-in CA) | Supports cert-based SSH (via integration) |
| Static key elimination | Yes (replaces keys) | No (manages existing keys) |
| Key discovery | N/A (no keys to discover) | Yes (scans all servers) |
| Key rotation | N/A (certs auto-expire) | Yes (policy-based rotation) |
| Key ownership tracking | N/A | Yes (maps keys to users/services) |
| Orphaned key detection | N/A | Yes (finds keys with no owner) |
| authorized_keys management | Replaced by cert trust | Yes (manages authorized_keys files) |
Audit & Compliance
| Capability | Teleport | QCecuring SSH KLM |
|---|---|---|
| Session recording | Yes (full terminal replay) | No |
| Session audit log | Yes (who accessed what, when) | Key operation audit trail |
| Compliance reports (SOX, PCI, HIPAA) | Access-focused reports | Key lifecycle compliance reports |
| Real-time session monitoring | Yes (live view) | No |
| File transfer audit | Yes | No |
| Key inventory report | N/A | Yes (complete key inventory) |
| Key age / rotation compliance | N/A (certs expire) | Yes (tracks key age vs policy) |
Infrastructure Scope
| Capability | Teleport | QCecuring |
|---|---|---|
| SSH server access | Yes | Yes (key management) |
| Kubernetes access | Yes (kubectl proxy) | Yes (via CertSecure for K8s certs) |
| Database access | Yes (PostgreSQL, MySQL, MongoDB) | No |
| Windows RDP | Yes | No |
| Internal web apps | Yes (application access) | No |
| TLS certificate management | No | Yes (via CertSecure CLM) |
| CBOM / crypto inventory | No | Yes (via CBOM product) |
Deployment
| Aspect | Teleport | QCecuring |
|---|---|---|
| Agent required on servers | Yes (Teleport agent) | Yes (discovery agent) |
| Self-hosted option | Yes (Teleport Enterprise) | Yes (single JAR) |
| Cloud/SaaS option | Yes (Teleport Cloud) | Yes |
| Open-source | Yes (Community Edition) | No |
| Infrastructure change | Significant (new access model) | Minimal (overlay) |
| Time to deploy | Weeks-months (migration) | Days-weeks (discovery) |
Where Teleport Wins
1. Zero Static Credentials
Teleport’s biggest advantage: there are no SSH keys to steal, leak, or forget to rotate. Short-lived certificates (default 8 hours) expire automatically. Even if an attacker captures a certificate, it’s useless within hours.
2. Complete Session Audit
Teleport records every SSH session — full terminal replay, file transfers, commands executed. This is invaluable for compliance (PCI DSS, SOX, HIPAA) and incident investigation. QCecuring tracks key operations but doesn’t record sessions.
3. Unified Infrastructure Access
Teleport isn’t just SSH — it’s a single platform for SSH, Kubernetes, databases, Windows, and web applications. One identity, one audit trail, one access policy across all infrastructure types.
4. Identity-Based Access (Zero Trust)
Access decisions are based on who you are (SSO identity + role), not what key you possess. This aligns with zero-trust architecture principles and eliminates the “shared key” anti-pattern.
5. Open-Source Core
Teleport Community Edition is open-source (Apache 2.0 licensed, 20K+ GitHub stars). You can evaluate and deploy without vendor commitment. QCecuring is commercial-only.
Where QCecuring Wins
1. Non-Disruptive Deployment
QCecuring discovers and manages existing SSH keys without changing your access model. No server agents to replace, no SSH configuration changes, no user workflow disruption. Teleport requires replacing your entire SSH access architecture — every server needs a Teleport agent, every user needs to change how they connect.
2. Existing Key Governance
Most enterprises have thousands of SSH keys accumulated over years — many orphaned, many never rotated, many with unknown owners. QCecuring provides visibility into this existing key estate. Teleport’s answer is “replace them all” — which is the right long-term goal but doesn’t help you govern what exists today.
3. Broader Cryptographic Scope
QCecuring’s SSH KLM is one product in a broader platform: TLS certificate management (CertSecure), cryptographic inventory (CBOM), code signing, and HSM management. If you need unified cryptographic lifecycle management, QCecuring covers more ground. Teleport is infrastructure access only.
4. Compliance for Key-Based Environments
Many compliance frameworks (PCI DSS, NIST 800-53) require documented SSH key management — inventory, rotation schedules, ownership, and access controls. QCecuring generates these compliance reports directly. Teleport’s compliance story is “we eliminated keys” — which satisfies the requirement differently but may not match auditor expectations for key management evidence.
5. Lower Migration Risk
Replacing SSH access infrastructure is a high-risk project. If Teleport deployment fails or has issues, users can’t access servers. QCecuring adds governance without changing access — if the platform has issues, SSH access continues working normally.
When to Choose Each
| Scenario | Choose |
|---|---|
| Greenfield infrastructure (new servers) | Teleport |
| Existing infrastructure with thousands of unmanaged keys | QCecuring (then migrate to cert-based later) |
| Zero-trust initiative | Teleport |
| Compliance audit requiring key inventory | QCecuring |
| Need session recording for SOX/PCI | Teleport |
| Need unified SSH + TLS + CBOM management | QCecuring |
| Small team, open-source preference | Teleport Community |
| Large enterprise, minimal disruption | QCecuring |
| Database + K8s + SSH unified access | Teleport |
| MSP managing multiple client environments | QCecuring |
The Hybrid Approach
Many organizations use both approaches:
- Phase 1: Deploy QCecuring to discover and inventory all existing SSH keys (immediate visibility)
- Phase 2: Identify orphaned keys, enforce rotation on remaining keys (reduce risk)
- Phase 3: Deploy Teleport for new infrastructure and high-security environments (modernize)
- Phase 4: Gradually migrate existing servers to Teleport as keys come up for rotation
- Phase 5: QCecuring continues managing TLS certificates and CBOM; Teleport handles SSH access
This phased approach reduces risk while moving toward the ideal state (certificate-based SSH everywhere).
Pricing Comparison
| Teleport | QCecuring SSH KLM | |
|---|---|---|
| Free tier | Community Edition (open-source) | No |
| Cloud pricing | Per-resource/month | Platform license |
| Self-hosted | Enterprise license (annual) | Platform license |
| Typical mid-market | $$-$$$ | $$ |
| Includes | SSH + K8s + DB + Windows access | SSH key management |
| Additional products | N/A (all-in-one access) | CertSecure, CBOM (separate) |
FAQ
Q: Can I use Teleport and QCecuring together?
Yes. Teleport handles SSH access (authentication, session recording, certificate issuance). QCecuring handles the broader cryptographic lifecycle (TLS certificates, key inventory, CBOM, compliance). They solve different problems and complement each other.
Q: Does Teleport eliminate the need for SSH key management?
For servers managed by Teleport — yes. But most enterprises have legacy systems, network devices, and third-party integrations that still use SSH keys. Teleport doesn’t manage those keys; it only manages access to servers running the Teleport agent.
Q: How long does Teleport migration take?
For a mid-size environment (500-2,000 servers): 2-6 months for full migration. This includes: agent deployment, SSO integration, role mapping, user training, and gradual cutover from key-based to certificate-based access. It’s a significant infrastructure project.
Q: Can QCecuring enforce certificate-based SSH?
QCecuring can manage SSH certificates (discovery, tracking, rotation) but doesn’t provide the SSH CA infrastructure itself. For certificate-based SSH, you’d use a CA (Vault, step-ca, or Teleport) for issuance and QCecuring for lifecycle governance.
Q: Which is better for compliance audits?
Depends on what the auditor asks. “Show me your SSH key inventory and rotation evidence” → QCecuring. “Show me who accessed what server and what they did” → Teleport. “Show me you’ve eliminated static credentials” → Teleport. Most audits want a combination.
Q: Is Teleport overkill if I only need SSH management?
If you only need SSH access management (not K8s, databases, Windows), Teleport still works — you just use the SSH module. But you’re deploying a full infrastructure access platform for one use case. If SSH key governance (not access replacement) is your primary need, QCecuring is more focused.
Related Reading: