Conjur uses industry-standard cryptography in several ways to protect your data. Much of Conjur cryptography is implemented in the open-source project slosilo. Slosilo is basically a wrapper around OpenSSL.


Conjur uses OpenSSL 1.0.2u with the FIPS flag enabled.

Cryptographic audit

Conjur cryptography has been professionally audited. We responded to all audit findings with the release of Slosilo 2.0.

Access tokens

Most requests to Conjur require an access token. Short-lived tokens help to secure identity, eliminate static access, and are useful for ephemeral environments to allow dynamic access to systems.

An access token is an industry-standard JSON Web Token (JWT). It is cryptographically signed by a Conjur private key, which includes the host or user id along with the expiration timestamp. The signing certificates are RSA 2048 keys.

Conjur uses OpenSSL (see our slosilo open-source project) to generate the RSA 2048 key pair, validate and sign the tokens.

The JWT contains the following claims:

Claim Description
sub The client's login name
iat Numeric timestamp at which the token was issued
exp (Optional) Numeric timestamp at which the token expires
cidr (Optional) List of IP netmasks which the request bearing this token must match

Protected JWS header should also include:

alg Signature algorithm; only is accepted. See slosilo for reference implementation. 
kid Fingerprint of the token-signing key.

Conjur access tokens are valid for 8 minutes after the iat unless an exp claim dictates otherwise.

The signature algorithm and access token implementation was included in the cryptographic audit.

Secret values

Secrets and API keys are encrypted with AES-256-GCM and stored securely in the Conjur database. The Conjur service has a unique 256-bit data key that is created when Conjur is first configured. Prior to encryption with the data key, secrets and API keys are prepended with the following:

  • Internal metadata that records some system state at time of encryption.

  • a fixed size random value that is used to prevent certain types of attacks

Securing this data key is essential. For more information about securing the data key, see Secure your server keys.


Encryption and decryption of secret values was included in the cryptographic audit.


Passwords are stored in the Conjur database using bcrypt, with a work factor of 12.

Storage and verification of passwords was included in the cryptographic audit.

FIPS compliance

  • The Conjur Server (Appliance) and the Kubernetes Authenticator Client are FIPS-compliant.

  • The Conjur Follower Operator and Conjur Kubernetes Follower have not been verified to be FIPS-compliant. However, they can be deployed into a Kubernetes/OpenShift cluster with FIPS mode enabled.

  • The Vault Synchronizer is FIPS-compliant when used on a FIPS-enabled Windows machine.

  • Third-party products that are used (such as NGINX) are shipped as is, and might not be FIPS-compliant.