Security overview
Last updated: 18 October 2026
Overview
CERTYX manages the certificates that keep your services trusted. That makes data security the first requirement, not an add-on. This overview describes, in general terms, how CERTYX protects your data and your infrastructure. It is written for security officers, architects and procurement teams. Configuration details are in the user guide, the agent installation guide and the SIEM integration guide; the contractual terms (service levels, subprocessors, retention, certifications) are set out in your customer agreement and data processing agreement.
Security by design
Three principles shape every part of the product:
The most sensitive material never reaches us. Private keys of managed certificates, certificate authority (CA) credentials and cloud credentials stay in your infrastructure. CERTYX works with public certificates, certificate signing requests and metadata.
Every organization is kept apart. Each customer organization has its own database and its own database roles, and every request, background task, agent and integration is bound to exactly one organization.
Every privileged action leaves evidence you can see. Changes, approvals, sign-ins and the actions of our own platform operators are recorded in a tamper-evident journal that you can review. Your SIEM receives your organization's own events and nothing else.
Isolation of your organization
Separate database per organization. Your inventory, policies, plans, jobs and journal are stored in a database of your own, reached with database roles of your own. Inside it, row-level security is forced, so even a query that forgot a filter cannot return another organization's rows.
Isolation in the shared platform layer as well. The few records that the platform keeps centrally (for example accounts, company sign-in settings, mobile devices, SIEM destinations and cloud sources) are protected by forced row-level security per organization too. Isolation is verified by automated cross-organization tests for every store.
Organization identity from the authenticated session only. The organization is never taken from a parameter a user could change. Workers, agents, SCIM provisioning, company sign-in and the mobile app are each bound to their organization.
Your keys and credentials stay with you
Private keys are generated where they are used. For a renewal, the CERTYX agent on the target host (or an agent acting as a relay over SSH for a host without an agent) creates the key and the certificate signing request locally. The private key is never sent to CERTYX; reports that contain private key material are refused.
Your certificate authorities stay in your control. Issuance through ACME, DigiCert CertCentral or your own Vault PKI is performed with credentials that remain on your side. SSH certificates are signed by a certificate authority on your own host.
Cloud vaults are read with your own identity. Certificates in Azure Key Vault, AWS Certificate Manager and Google Certificate Manager are imported read-only with your own command-line session. No cloud credentials are entered in CERTYX.
Protection of the secrets CERTYX must hold
Some settings require a secret on the platform, for example the password of your SMTP relay, a SIEM token, a company sign-in client secret or the seed of an authenticator app.
These secrets are encrypted at rest and bound to your organization: a value copied into another organization's records cannot be decrypted there.
They are write-only: once saved they are never shown again, never returned by the API and never written to logs or the journal.
On the hosted service, the keys that encrypt them are protected by a dedicated key in AWS KMS: every decryption is a logged call to KMS, so a copy of the database together with the server's files is not enough to read them.
Agents and software supply chain
Mutual TLS with enrolled identities. Every agent proves its identity with its own client certificate. An agent is enrolled with a one-time code that expires after ten minutes; a newly enrolled network agent may only discover, and deployment rights are granted separately.
Outbound connections only. Agents connect to CERTYX; no inbound port has to be opened on your hosts.
Local scope enforcement. Agents refuse jobs outside the destinations configured on them, whatever the server asks.
Signed packages and updates. Agent packages carry the publisher's signature, which the installer checks against a fingerprint you obtain independently, and refuses to install on mismatch. Automatic updates are signed with an offline release key and checked for integrity and against downgrades before they are applied.
Reproducible builds. The agent release process builds the binaries reproducibly and records a software bill of materials (SBOM) and a build record with every package.
Sign-in and access
Multi-factor authentication. Administrative actions require MFA. Authenticator codes cannot be replayed, and single-use recovery codes are stored only in hashed form.
Passkeys. Phishing-resistant passkeys (WebAuthn) can be used as the second factor at sign-in and for confirmations.
Company sign-in and provisioning. Microsoft Entra ID, Okta, any OpenID Connect provider or SAML 2.0, with user names checked against the e-mail domains verified for your organization, and SCIM provisioning. Changes that raise a role through your identity provider are journaled.
Network allowlists. Your administrators can restrict sign-in to your organization to approved IP addresses and ranges (IPv4 and IPv6).
Sessions under your control. Sessions are short, with an idle timeout. Users and administrators see the active browser and mobile sessions and can end a single session or all others immediately. A password, MFA or account change ends existing sessions.
Brute-force protection. Repeated failed sign-ins lock the account for a growing period, and repeated failures raise an alert.
Roles and four eyes. Auditor, Operator and Admin roles separate reading, operating and administering. Renewals and SSH signing profiles can require approval by a second administrator.
Mobile devices. The CERTYX mobile app works only on devices your administrator activated with a one-time code. Every request is signed with a key held in the device's secure hardware that cannot be exported, and a revoked device is refused on its next request.
Platform operator access: under your control
CERTYX staff who run the hosted service are subject to the same principles as your users, and to more:
Least privilege. Operators have separate roles (support, commercial, security administration, administration); each sees only the areas its role requires. Raising an operator's role needs the approval of a second operator.
Step-up confirmation. Control-room changes that affect access or data flow require a fresh MFA confirmation.
Your approval first. Creating an account in your organization, raising a role, re-enabling an account or resetting MFA requires approval by one of your administrators. The only alternative is a time-limited break-glass with a stated reason and a second operator, and every break-glass is e-mailed to all your administrators.
Visible to you. Every operator action that affects your organization is recorded in your own security journal and shown in your console. Platform logs never go to your SIEM, and your logs never go to another organization: the platform operator sets separate destinations for platform logs.
What operators never get. Private keys and CA or cloud credentials are not on the platform, so operators cannot see them; stored SMTP, SIEM and company sign-in secrets cannot be read through any interface.
Evidence, audit and SIEM
Tamper-evident security journal. Every security-relevant event is chained to the previous one with a cryptographic hash; the console verifies the integrity of the chain and exports any filtered selection as CSV or JSON. On the hosted service, the journal is anchored every hour: a signed anchor is stored in write-once storage, so that a later change to anchored events can be detected independently of the database.
SIEM export in open standards. CEF, LEEF 1.0 and 2.0, RFC 5424 syslog, NDJSON, Generic KV and CSV, with the OCSF, Elastic Common Schema and Splunk CIM schema profiles, to Splunk, Cribl, IBM QRadar, ArcSight, Elastic, Microsoft Sentinel, OpenTelemetry backends or your own collector.
Encrypted transport, always. Export uses TLS with certificate validation and revocation checking; client certificates (mutual TLS) are supported. Unencrypted syslog is not offered.
Nothing lost silently. The journal itself is the delivery queue. When a receiver is unavailable, events wait and alerts are raised if delivery keeps failing; refused events are journaled and can be sent again after the receiver is fixed.
Every change verified. After a deployment, the result is verified independently against the live endpoint, and a failed deployment is rolled back.
AI Trust Analyst
The AI Trust Analyst answers questions about your certificate estate in plain language.
It is off until an administrator of your organization enables it after reading the data notice.
It works only through read-only tools scoped to your organization; it cannot create, change, approve or delete anything.
Every answer cites the records it used.
Private keys, passwords, tokens, secrets and certificate files are never sent to the AI provider. Your administrator sets how long conversations are kept, including not at all.
Infrastructure and operations of the hosted service
Hosted in the EU. The hosted service runs in the AWS Frankfurt region (eu-central-1).
Encryption in transit everywhere. Browser, mobile, agent and integration traffic uses TLS, with strict transport security on the web. Connections to the databases inside the platform are encrypted as well, with full certificate verification.
Hardened web application. A strict content security policy, protection against clickjacking and cross-site request forgery, rate limits and generic error answers without internal details.
Encrypted backups. Backups are encrypted with authenticated encryption before they leave the server and are uploaded every day to versioned, write-once storage with a 30-day retention lock. A restore verifies every part before any data is changed.
Dedicated encryption keys and audit trail. The database, the server disks, backup and release storage and the key ring that protects your secrets are encrypted with dedicated keys in AWS KMS that rotate every year. Management actions in the cloud account, including every use of these keys, are recorded in a cloud audit trail with log-file validation, kept in separate encrypted write-once storage.
Controlled administration. The hosted server cannot be reached over SSH; administrative access goes through an audited management channel. Releases are deployed from tagged builds through an automated pipeline, with container images pinned by digest and release archives verified by checksum.
Tested resilience. Database outages, instance crashes, restores and a failover between two instances have been exercised in recorded drills on a test installation; in the failover drill, no client request failed.
Privacy and GDPR
Named controller. The privacy policy names the controller of personal data and how to reach them.
Data processing agreement. The terms of processing on your behalf (GDPR Art. 28) are published on the data processing page and set out in your data processing agreement.
No tracking without consent. The public website uses only necessary storage by default. Optional web analytics run only after consent and never on the sign-in pages or in the console. No advertising.
Deployment options
CERTYX is available as a hosted service operated by CERTYX, or in your own data centre or cloud account. A deployment in your own AWS account can use the same cloud protections as the hosted service, with the encryption keys and the cloud audit trail in your account. Sales confirms which options fit your plan.
Contact
Website: https://certyx.space
Sales: sales@certyx.space
Technical support and security questions: support@certyx.space
Please report a suspected vulnerability to support@certyx.space.