"What if OnePAM gets hacked?"
It's the right question to ask about any SaaS product you connect to your infrastructure. Here's an honest, technical breakdown of what an attacker could and could not do — even in a worst-case breach of OnePAM's control plane.
Understand the Architecture First
OnePAM separates the control plane (policy, identity, audit) from the data plane (gateways, secrets, connections). This separation is the foundation of why a breach of OnePAM's cloud does not equal a breach of your infrastructure.
The control plane never sees your credentials, SSH keys, or database passwords. It only decides who is allowed to connect and what policies apply. The actual connection and secret resolution happen exclusively inside the gateway — which sits in your network, under your control.
Attack Scenarios & What Actually Happens
We've modeled realistic attack scenarios so you know exactly what the blast radius would be. No hand-waving — just facts.
Scenario: OnePAM's database is breached
An attacker gains read access to OnePAM's control plane database. What can they see?
- Organisation names, user emails, team structures
- Cannot see: passwords (bcrypt-hashed), SSH keys, database credentials, or any secret you stored
- Cannot see: the content of your SSH sessions, RDP sessions, or database queries
Metadata exposure (who uses OnePAM, which resources exist). No credentials, no access to your servers, no session content.
Scenario: Attacker takes over the control plane
An attacker gets full administrative access to OnePAM's control plane. Worst case.
- Could modify access policies (e.g., grant themselves access to resources)
- Still cannot: read secrets stored on your gateway or agent (zero-knowledge encryption)
- Blocked if: you use a customer-managed gateway with gateway restriction (Business+)
With gateway restriction enabled, the attacker cannot route traffic through your gateway because mTLS certificates are pinned. Your gateway rejects unknown connections.
Scenario: Network traffic is intercepted
An attacker performs a man-in-the-middle attack between agents/gateways and the control plane.
- All agent-to-gateway communication uses mutual TLS (mTLS) with certificate pinning
- Certificates are validated on both sides — a fake certificate is immediately rejected
- All control plane communication uses TLS 1.3 with perfect forward secrecy
None. mTLS with certificate pinning makes man-in-the-middle attacks infeasible. The connection simply fails rather than downgrade.
Scenario: An employee's OnePAM account is compromised
An attacker steals a user's credentials and logs into OnePAM with their identity.
- MFA required: Even with the password, the attacker needs a second factor
- RBAC enforced: The compromised user can only access resources their role permits
- Full audit trail: Every session, command, and access attempt is logged and alertable
Limited to the user's exact permissions. All actions are recorded in immutable audit logs, enabling rapid detection and revocation.
Blast Radius: OnePAM vs Traditional Approaches
Compare what happens when different access solutions are compromised.
| If compromised... | Traditional VPN | Bastion / Jump Host | OnePAM |
|---|---|---|---|
| Credentials exposed? | VPN creds give full network access | SSH keys on bastion are accessible | Secrets resolved within your infrastructure; network access keys are per-user with auto-expiry |
| Lateral movement? | Full network access once inside | Limited by SSH configs | Zero Trust — VPN uses per-user split tunneling with RBAC |
| Session visibility? | No session recording | Manual audit log setup | Every session recorded and auditable |
| Access revocation? | Revoke VPN cert (slow) | Remove keys from all hosts | Instant — revoke user/policy centrally |
| Vendor breach impact? | N/A (self-hosted but no segmentation) | N/A (self-hosted but keys at risk) | No credential exposure (zero-knowledge) |
| Overall blast radius | Critical | Moderate | Minimal |
7 Layers Between an Attacker and Your Resources
Even in a breach of OnePAM's cloud, an attacker would need to defeat every single layer to reach your infrastructure.
Control Plane Hardening
WAF, DDoS protection, rate limiting, IDS/IPS, network segmentation. Getting into OnePAM's infrastructure is the first barrier — and it's heavily defended.
Zero-Knowledge Secret Architecture
Even with full database access, secrets are never stored on the control plane. Agents resolve target credentials locally from encrypted storage, and gateway-backed database sessions hold only ephemeral in-memory credentials for the life of the active connection.
Mutual TLS (mTLS) with Certificate Pinning
Agent-to-gateway communication requires both sides to present valid, pinned certificates. An attacker cannot impersonate either side, even if they compromise the control plane.
Customer-Managed Gateway Restriction
Business and Enterprise customers can enforce that all traffic flows through their own gateway instances. The gateway rejects any connection that doesn't originate from a known, certificate-authenticated source.
Identity Verification & MFA
Every access request requires identity verification. MFA (TOTP, WebAuthn) adds a second factor that an attacker cannot bypass even with stolen credentials.
Role-Based Access Control (RBAC)
Users can only access the specific resources their role permits. No implicit trust, no network-level access. Even a compromised admin account is scoped to their organisation's resources only.
Immutable Audit Logs & Anomaly Detection
Every action is logged in append-only audit logs that cannot be tampered with. Unusual access patterns trigger alerts, enabling rapid detection and response even if other layers are bypassed.
Harden Your Setup Even Further
OnePAM is designed to be safe by default, but you can take additional steps to maximise your security posture.
Gateway Security
- Deploy your own gateway inside your network perimeter for full data-plane control
- Enable gateway restriction to block OnePAM-hosted gateways entirely (Business+)
- Use local secret storage so credentials are encrypted at rest in the agent's vault
- Restrict gateway network access using firewall rules to only allow connections to specific resources
Identity & Access
- Enforce MFA for all users via organisation policy (TOTP or WebAuthn)
- Use SSO/SAML to centralize identity and inherit your IDP's security policies
- Apply least-privilege RBAC — give users access only to the resources they need
- Enable domain-based provisioning with DNS verification for automatic user onboarding
Monitoring & Response
- Review audit logs regularly for unexpected access patterns or unusual activity
- Set up alert rules for failed login attempts, new endpoint enrollments, or policy changes
- Export logs to your SIEM for centralized security monitoring and correlation
- Store credentials securely using vault integration or the local encrypted secret store
Frequently Asked Questions
Direct answers to the tough questions security teams ask.
Does OnePAM have access to my servers?
Can OnePAM read my SSH sessions or database queries?
What if I don't trust OnePAM-managed gateways?
What data does OnePAM store about my infrastructure?
Is the OnePAM agent safe to run on production servers?
What happens if OnePAM goes down?
Can I self-host OnePAM entirely?
Has OnePAM ever been breached?
Still Have Security Concerns?
We welcome scrutiny. Our security team is available to walk through our architecture or discuss your specific threat model.