What Cloudflare Access Does Well
Cloudflare Access is a zero-trust network access (ZTNA) product that sits at Cloudflare’s global edge. It authenticates users via your identity provider, evaluates device posture policies, and then proxies connections to your internal services. For web applications—internal dashboards, admin panels, staging environments—it works exceptionally well.
The deployment model is elegant: install a lightweight cloudflared connector in your network, define access policies in the Cloudflare dashboard, and users access internal services through their browser with no VPN required. The global edge network provides low latency regardless of user location, and the integration with Cloudflare’s broader security stack (WAF, bot management, DDoS protection) creates genuine defense-in-depth for web traffic.
The Gap: Privileged Infrastructure Access
Cloudflare Access answers the question: “Should this user be allowed to reach this service?” That is an essential question for network access control. But for privileged infrastructure—production servers, databases, Kubernetes clusters—a second question matters equally: “What did this user do after they connected?”
This is the session layer that Privileged Access Management (PAM) provides. Cloudflare Access operates at the network edge. PAM operates at the session level. They are complementary, not competitive.
Cloudflare Access controls who can reach infrastructure at the edge; PAM controls and records what happens inside the session
Five Gaps Where Teams Need PAM Beyond Cloudflare Access
1. Session Recording
Cloudflare Access logs connection events: user X connected to service Y at time Z from device W. It does not record what happened during the SSH session, which database queries were executed, or what Kubernetes commands were run. For compliance frameworks (SOC 2, ISO 27001, HIPAA, PCI-DSS), connection logs are necessary but insufficient. Auditors want to see the session content.
2. Database Access Governance
Cloudflare Access can route TCP connections to a database port. It cannot parse database protocols, log individual queries, enforce row-level access policies, or provide a managed SQL interface. For production database access—where a single DELETE FROM users; can be catastrophic—protocol-aware governance is essential.
3. Just-in-Time Access with Approval Workflows
Cloudflare policies are binary: a user either matches the policy or they don’t. PAM platforms provide temporal access with approval chains: “Grant this engineer read-only access to the production database for 2 hours, require manager approval, and auto-revoke when the window closes.” This workflow doesn’t exist in Cloudflare’s model.
4. Compliance Evidence Generation
When an auditor asks “Show me evidence that production access is reviewed quarterly” or “Demonstrate that access is revoked within 24 hours of role change,” you need structured evidence packages. PAM platforms generate these natively. Cloudflare Access logs would require custom tooling to produce equivalent evidence.
5. Credential Lifecycle Management
Cloudflare Access authenticates the user at the edge. It does not manage the credentials used to authenticate to the target infrastructure. Someone still needs to provision, rotate, and revoke SSH keys, database passwords, and kubeconfig tokens. PAM platforms handle this lifecycle end-to-end.
| Capability | Cloudflare Access | OnePAM (PAM Layer) |
|---|---|---|
| Identity verification | Yes—SSO + device posture | Yes—SSO + MFA per session |
| Network-level access control | Yes—global edge enforcement | Limited—operates at session level |
| SSH session recording | No | Yes—full terminal capture with playback |
| Database query logging | No—TCP only | Yes—protocol-aware, per-query |
| Kubernetes session recording | No | Yes—command capture and API audit |
| JIT access workflows | No—static policies only | Yes—approval chains, time windows, auto-revoke |
| Credential management | No—bring your own credentials | Yes—JIT credential generation and rotation |
| Compliance evidence export | Connection logs only | Structured reports with session recordings |
| Web application access | Excellent—primary use case | Supported via browser-rendered proxy |
The Complementary Architecture Pattern
For many organizations, the optimal architecture uses both tools in their respective strengths:
- Cloudflare Access for web applications: Internal dashboards, admin panels, CI/CD UIs, monitoring tools
- OnePAM for privileged infrastructure: Production SSH, databases, Kubernetes clusters, network devices
- Cloudflare Access as the outer perimeter: Authenticate users before they reach the PAM layer
- OnePAM as the session layer: Record, control, and audit what happens after authentication
This layered approach means Cloudflare handles what it does best—identity-aware routing at the edge with DDoS protection and bot mitigation—while OnePAM handles what it does best—session governance, recording, and compliance evidence for privileged access.
Architecture Pattern
Use Cloudflare Access as the “front door” (network admission) and OnePAM as the “session room” (activity governance). Users authenticate once at the edge, then OnePAM applies resource-level policies, records sessions, and manages credential lifecycle for privileged infrastructure.
Routing Rules: When to Use Each Tool
| Access Pattern | Recommended Tool | Rationale |
|---|---|---|
| Internal web dashboards (Grafana, Jenkins, etc.) | Cloudflare Access | Web-native, no session recording needed |
| Production SSH to servers | OnePAM | Session recording, command auditing, JIT access required |
| Production database queries | OnePAM | Query-level logging, credential management, access approval needed |
| Kubernetes cluster access | OnePAM | Command recording, namespace-scoped access, auto-expiry |
| Staging environment web apps | Cloudflare Access | Lower risk, identity verification sufficient |
| Vendor troubleshooting sessions | OnePAM | Time-limited, recorded, approved, browser-native for vendors |
| Internal APIs and microservices | Cloudflare Access | Service-to-service or developer access to API docs |
Implementation Approach
If you already have Cloudflare Access deployed and want to add PAM capabilities for privileged infrastructure:
- Week 1: Deploy OnePAM agent on 3–5 production servers already behind Cloudflare Access
- Week 2: Configure SSO integration (same IdP as Cloudflare) and define access policies
- Week 3: Enable session recording and JIT access workflows for the pilot group
- Week 4: Run a mock audit—generate compliance evidence and review session recordings
- Week 5: Expand to databases and Kubernetes clusters based on pilot results
The key insight is that you don’t need to replace Cloudflare Access. You add OnePAM alongside it for the resources that require session-level governance. Cloudflare continues to handle network admission and web application access. OnePAM handles the privileged session layer.
Common Mistake
Teams sometimes try to use Cloudflare Access’s SSH tunneling (cloudflared) as their complete SSH governance solution. While it authenticates users, it produces no session recordings, no command logs, and no compliance evidence. This creates a false sense of security that fails the first time an auditor asks “what commands did this user run on the production database server?”
Cost Considerations
Running both tools creates a combined cost, but the alternative—trying to force one tool to cover both use cases—typically costs more in operational complexity and compliance gaps. Organizations that try to build PAM-grade evidence on top of Cloudflare Access alone end up scripting custom log collectors, building homegrown approval workflows, and maintaining side-channel recording infrastructure that costs more than a purpose-built PAM layer.
The economic question is not “can we avoid paying for a second tool?” but “what does the compliance gap cost when an auditor finds it?” Failed audit findings, delayed SOC 2 reports, and breach-related privilege escalation carry costs that dwarf the license difference between running one platform versus two complementary ones.
| Cost Factor | Cloudflare Access Only | Cloudflare Access + OnePAM |
|---|---|---|
| Web application access | Covered—per seat pricing | Covered by Cloudflare Access |
| SSH session recording | Not available—requires custom build | Covered by OnePAM |
| Database governance | Not available—requires separate tool | Covered by OnePAM |
| Compliance evidence | Partial—connection logs only | Complete—sessions + queries + approvals |
| Custom tooling to fill gaps | High—build recording, JIT, audit | None—both layers are covered |
The total cost of Cloudflare Access plus OnePAM is typically lower than Cloudflare Access plus the engineering time required to build session recording, JIT access workflows, and compliance reporting from scratch. Most teams that attempt to build these capabilities internally underestimate the ongoing maintenance burden—especially as compliance requirements evolve and audit scope expands.
Measuring the Combined Architecture
After deploying both layers, track these metrics to validate that the architecture is delivering value:
- Coverage gap: Percentage of privileged access that lacks session recording. Target: 0%
- Audit response time: Time from auditor request to evidence delivery. Target: under 1 hour
- Mean time to access (web apps): Unchanged from Cloudflare-only baseline
- Mean time to access (infrastructure): Under 5 minutes including approval for JIT access
- Compliance finding reduction: Fewer access control findings in annual SOC 2 audit
Related Resources
- Full Cloudflare Access vs OnePAM comparison
- Cloudflare Access alternatives for infrastructure access
- Browser-based SSH with session recording
- Web application access management
- Session recording documentation
Add Session Governance to Your Cloudflare Stack
Keep Cloudflare Access for web apps. Add OnePAM for SSH, database, and Kubernetes session recording, JIT access, and compliance evidence. Deploy in minutes alongside your existing Cloudflare setup.
Start Free Trial