Bastion hosts have been the standard for secure server access for decades. You place a hardened jump server in a public subnet, SSH into it, then hop to your private instances. Simple and battle-tested.
But bastion hosts come with hidden costs. You must patch them constantly. You must monitor them 24/7. You must manage SSH keys across your entire team. And when your SOC 2 auditor asks "who accessed what server and when?", you scramble to piece together logs from a dozen different sources.
This is the story of how we helped a SaaS company replace 23 bastion hosts across 15 AWS accounts with Zero Trust architecture. The result: eliminated infrastructure overhead, zero SSH keys to manage, and a clean SOC 2 audit.
See the full business impact in our case study →
TL;DR
- Problem: 23 bastion hosts across 15 AWS accounts, 70+ SSH keys, 24 SOC 2 findings, dev/staging sites exposed to the internet
- Solution: JumpCloud (identity + device trust) → AWS SSM for servers, Cloudflare Zero Trust for applications
- Results: Zero bastion hosts, zero SSH keys, 96% fewer audit findings, all internal sites behind conditional access
- Biggest win: DevOps engineers SSO into any of the 15 AWS accounts instantly. No more copy-pasting access keys and session tokens
The Problem: SSH Keys Everywhere, Dev Sites Exposed
The client operated 33 AWS accounts across multiple products. We worked with 15 of those accounts, each with its own bastion host (some had two for availability). Their infrastructure had grown organically without a unified access strategy.
Loading diagram...
The pain points:
- 23 bastion hosts across 15 AWS accounts costing ~$1,400/month
- 70+ servers with SSH keys scattered across developer laptops
- No central inventory of which keys exist on which servers
- Terminated employees might still have valid keys somewhere
- 10+ engineering hours weekly on access management and key rotation
- 24 SOC 2 security findings related to access control
- Dev and staging sites on multiple subdomains fully exposed to the internet
That last point was a silent risk. Static sites, internal tools, and staging environments had no authentication. They relied on "security through obscurity." Anyone who guessed the subdomain had full access. Search engines were indexing some of them.
The Solution: Zero Trust for Servers AND Applications
Zero Trust means "never trust, always verify." We applied this principle to both server access AND application access using JumpCloud as the identity foundation.
Loading diagram...
Three Layers of Protection
JumpCloud for identity and device trust:
JumpCloud verifies who you are AND that your device is authorized. MFA is enforced at the device login itself—engineers authenticate with username, password, and MFA just to unlock their laptop. Conditional access policies then enforce that only company-managed devices with proper security posture can access corporate resources. No authorized device? No access to anything.
AWS SSM for server access:
SSM Session Manager replaces SSH entirely. No keys to manage, no ports to open, full session recording. IAM controls who can access which servers. Permissions flow from JumpCloud groups through federation.
Cloudflare Zero Trust for application access:
This solved our biggest gap. All those exposed dev sites, staging environments, and internal tools without built-in authentication? We put them behind Cloudflare Zero Trust. Now they require corporate identity verification before loading a single byte.
Cloudflare WAF/CDN for public applications:
Production sites that need to be public still get Cloudflare's WAF, DDoS protection, and CDN. The difference: public sites have their own authentication, internal sites are protected by Zero Trust.
Closing the Exposed Application Gap
Before our engagement, the client had a sprawling problem they didn't fully recognize.
Loading diagram...
Multiple subdomains across their products were publicly accessible:
- Development environments with test data
- Staging sites mirroring production
- Internal documentation and wikis
- Static sites and admin panels without login
The "protection" was hoping nobody found the URLs. Some had been indexed by Google. Some had been discovered by security scanners and added to breach databases.
Loading diagram...
After Cloudflare Zero Trust:
Every internal application now requires authentication through Cloudflare Access. Users authenticate once via JumpCloud (which Cloudflare trusts as an identity provider), and conditional access policies apply. Only users on corporate-managed devices can reach these sites.
Someone finds your staging URL? They see a login screen. They try to authenticate with personal credentials? Blocked. Device isn't enrolled. The subdomain could be posted on Reddit and it wouldn't matter.
What Engineers Actually Use Now
Here's what really sold the engineering team: no more credential juggling.
Before: The Daily Frustration
Every DevOps engineer knows this pain. You need to access a production server in one of 15 AWS accounts:
- Run
aws sso login - Open browser, authenticate
- Copy the access key ID
- Copy the secret access key
- Copy the session token
- Paste into terminal or credentials file
- Hope you got the right account
- Repeat for each AWS account you need
With 15 AWS accounts in scope, this was a daily time sink. Engineers would keep credentials in plaintext files. Some shared session tokens over Slack. Security nightmare.
After: One Command, Any Account
We deployed ZTiAWS, an open-source CLI toolkit that makes AWS access effortless.
Loading diagram...
SSO into any account instantly:
Engineers run ztictl auth login once. A fuzzy finder shows all their permitted accounts and roles across all 15 AWS accounts. Select one, and they're authenticated. No copy-pasting. No credential files. Session credentials are handled automatically.
Connect to any server in seconds:
Run ztictl ssm connect --region use1. An interactive fuzzy finder shows all instances they have access to. Search by name, ID, or tags. Select one and they're connected. No instance IDs to memorize. No SSH keys to manage.
Execute commands across fleets:
Need to check disk space on all production web servers? One command runs across every matching instance and returns aggregated results.
The feedback from engineers was immediate: "This is how AWS should have always worked."
The Complete Zero Trust Stack
Here's how the pieces fit together:
| Layer | Tool | What It Protects | How |
|---|---|---|---|
| Identity & Device | JumpCloud | Everything | SSO, MFA, conditional access, device posture |
| Server Access | AWS SSM | EC2 instances | Session Manager, no SSH, full logging |
| Internal Apps | Cloudflare Zero Trust | Dev, staging, tools | Access policies, identity verification |
| Public Apps | Cloudflare WAF/CDN | Production sites | DDoS, WAF rules, performance |
Why this separation matters:
JumpCloud is the source of truth for identity. Both AWS (via SAML federation) and Cloudflare (via identity provider integration) trust JumpCloud. One place to manage users, one place to enforce device policies, consistent access controls everywhere.
The Critical Security Win: Conditional Access
This is the piece most Zero Trust implementations miss. They verify identity but trust any device.
Loading diagram...
Our conditional access policy requires:
- Device enrolled in JumpCloud MDM
- MFA at device login (username + password + MFA to unlock)
- Full disk encryption enabled
- Firewall active
- OS version within supported range
- Company-approved endpoint protection running
If any condition fails, no access. Not to servers, not to applications. The engineer sees an error explaining which device requirement isn't met.
Why this matters:
- Lost laptop? Can't access AWS or internal sites
- Personal device? Blocked at JumpCloud
- Compromised machine without EDR? No access
- Former employee's device? Automatically blocked when MDM enrollment is removed
The device IS the perimeter.
Implementation: 14 Weeks to Zero Trust
Phase 1: JumpCloud Foundation (Weeks 1-3)
We configured JumpCloud as the identity provider with conditional access policies enforcing device trust. SAML federation to AWS IAM Identity Center was established with SCIM provisioning for automatic user sync. JumpCloud groups mapped to AWS permission sets.
Phase 2: SSM Rollout (Weeks 4-7)
SSM Agent was deployed across all 70+ instances in the 15 AWS accounts. VPC endpoints were created in each account for private SSM communication. Session logging to centralized S3 buckets was configured. We tested access in parallel with existing bastion hosts.
Phase 3: Cloudflare Zero Trust for Applications (Weeks 6-7)
We audited all subdomains and identified 12 sites that were exposed without authentication. Each was placed behind Cloudflare Access with JumpCloud as the identity provider. Access policies mirrored the conditional access requirements. Same device trust rules applied.
Phase 4: Tooling & Training (Weeks 8-10)
We deployed ZTiAWS across all engineering laptops. Training sessions covered the new workflow for both server access (ztictl) and application access (just authenticate once, Cloudflare handles the rest).
Phase 5: Hardening & Decommission (Weeks 11-14)
SSH keys were removed from all servers. Security groups were updated to remove port 22. Bastion hosts were stopped with a 7-day rollback window, then terminated. Final audit confirmed zero exposed access paths.
SOC 2 Results
The transformation directly addressed audit findings:
| Category | Before | After | How |
|---|---|---|---|
| Access Logging | 7 findings | 0 | SSM logs every session |
| Key Management | 9 findings | 0 | No SSH keys exist |
| Session Recording | 5 findings | 0 | Full capture to S3 |
| Exposed Applications | 2 findings | 0 | Cloudflare Zero Trust |
| Access Reviews | 1 finding | 1 | JumpCloud reports |
| Total | 24 | 1 | 96% reduction |
The 1 remaining finding was a documentation item.
Cost Analysis
Before:
- ~$1,400/month for 23 bastion hosts
- Unquantified risk from exposed dev/staging sites
After:
- ~$120/month for VPC endpoints and session logging
- Cloudflare Zero Trust (included in existing Cloudflare plan)
Net infrastructure savings: ~$15,000/year
Real savings: The exposed staging sites could have been a breach. One compromised staging environment with access to test data or internal APIs could have cost far more than the entire project.
Lessons Learned
Protect applications, not just servers. Everyone focuses on SSH access. Meanwhile, staging sites with no authentication are sitting on public subdomains. Zero Trust means protecting everything.
Device trust is non-negotiable. Identity alone isn't Zero Trust. Without conditional access enforcing device compliance, you're just moving the perimeter.
Developer experience drives adoption. Engineers embraced the change because ztictl made their daily work easier. Cloudflare Zero Trust was invisible to them. Just authenticate once and sites load. Security that slows people down gets bypassed.
Audit your subdomains. The client didn't realize how many internal sites were exposed until we ran a full subdomain enumeration. You probably have the same problem.
Use each tool for what it's best at. JumpCloud for identity, SSM for server access, Cloudflare Zero Trust for application access, Cloudflare WAF for public sites. Trying to force one tool to do everything creates complexity.
Conclusion
Bastion hosts and "hidden" internal sites were security debt from a faster-moving era. Zero Trust architecture offers something better:
- True security: Identity AND device verification for everything
- No blind spots: Internal applications protected, not just servers
- Better compliance: Complete audit trail by default
- Better experience: Engineers actually prefer it
The 14-week investment paid for itself within the first year. More importantly, it closed security gaps the client didn't know they had.
Read the full case study with business impact →
Tools referenced:
- ZTiAWS (ztictl) — Open-source CLI for AWS SSO and SSM operations
- Cloudflare Zero Trust — Application access protection
- JumpCloud — Identity and device management
Ready to eliminate your bastion hosts and protect your exposed applications? We help SaaS companies implement Zero Trust architecture that passes audits and closes security gaps. Schedule a consultation →
