ConductorOne Docs

Security architecture

ConductorOne is built for security and scale on a modern technical architecture.

Security at ConductorOne

At ConductorOne, our team is composed of long-time experts in security, identity, and infrastructure, who have built products from the ground up with highly secure environments.

We understand that our own security and privacy practices are mission-critical to our ability to provide modern privileged access and governance for our customers.

Employee access

  • Our internal systems use SSO and multi-factor authentication whenever possible.

  • Secure password vaults are used for storing credentials when SSO is not supported by a system.

  • No internal tooling or dashboards grant employee access to customer API keys or secrets.

  • Background checks are performed annually for all employees. Security training is provided annually for all employees.


Employees do not have access to production servers (we only use AWS EKS Managed Node Groups with no remote access). No workstations have network access to staging or production environments. WiFi in offices provides no additional permissions or authorization grants.

Service availability

Our infrastructure is deployed across multiple availability zones (US West2 and US East2). Disaster recovery dry-runs are performed annually. Data in our object store (DynamoDB) is backed up continuously. Data is replicated across AWS regions.

Data and infrastructure

Tenant isolation is ensured through decryption controls within tenant boundaries. All traffic to ConductorOne is encrypted using TLS 1.2 and greater. All internal services and traffic use mutual TLS. All objects are stored and encrypted at rest in AWS DynamoDB. API keys and secrets are encrypted with AWS KMS symmetric keys and encrypted again at rest in storage. Internet-facing API services are unable to decrypt data. Explicit firewall rules govern all service communications. Services employ highly specific security groups, managed in code.