Roadmap
What we're building next. Items on this page are planned, not yet shipped — no committed dates. If one of these is important to your rollout, tell us and we'll prioritize.
Planned distribution targets
These will join the existing distribution modules (see Distribution) with the same model: a target + credential + module config, then automatic deploy/renew.
| Target | What it will do | Status |
|---|---|---|
| Google Cloud Certificate Manager | Upload the certificate as a self-managed certificate in Google Cloud (Certificate Manager / load-balancer SSL certificate) so GCP HTTPS load balancers serve the renewed cert. Auth via a GCP service account. | Planned |
| Fortinet FortiGate (via FortiManager) | Import the certificate and bind it to the policies / SSL-inspection profiles that reference it, pushed centrally through FortiManager. Clone-not-modify to preserve existing bindings. | Planned |
| Palo Alto Networks (PAN-OS / Panorama) | Direct PAN-OS firewalls have shipped as the PAN-OS module: the certificate is imported as a named certificate object and committed with a partial commit scoped to CertAutoPilot's API user, so existing SSL/TLS service profile and GlobalProtect bindings are preserved on every renewal. Centralized push through Panorama (template / device-group push) remains planned. | PAN-OS: Shipped · Panorama: Planned |
| A10 Thunder (ADC) | Import the certificate and update the referencing SSL templates / virtual services on A10 Thunder application delivery controllers via the aXAPI, in place so existing bindings are preserved. | Planned |
Planned issuing CAs
New certificate sources (get certs from), alongside the shipped ACME and Microsoft AD CS issuers.
| Issuer | What it will do | Status |
|---|---|---|
| HashiCorp Vault PKI | Use a Vault PKI secrets engine as an issuing CA — CertAutoPilot signs the CSR through Vault's pki/issue (or pki/sign) endpoint and manages the lifecycle, so an internal Vault-backed CA joins ACME and AD CS as a first-class issuer. (Vault is already supported as a distribution target for storing certs — this adds Vault as an issuer.) | Planned |
Planned credential sources / integrations
Where target credentials come from — beyond CertAutoPilot's own envelope-encrypted store.
The foundation here has shipped: a credential can already declare an external secret store as its source, with the value read from the store on every use rather than stored — HashiCorp Vault, OpenBao and ManageEngine PAM360 are the supported stores. The integrations below add further products on that same foundation; none of them changes how stores or credentials are configured.
| Integration | What it will do | Status |
|---|---|---|
| CyberArk (dynamic credentials) | Fetch a target's credential from CyberArk at deploy time, so CyberArk's rotation stays transparent — CertAutoPilot always uses the current secret. Agentless via the Central Credential Provider (CCP) REST API with mutual-TLS or allowed-machine authentication; no target password is ever stored in CertAutoPilot. | Planned |
| Delinea Secret Server | Read target credentials from Delinea (formerly Thycotic) Secret Server at deploy time, addressing a secret by its ID or folder path via the REST API. | Planned |
| BeyondTrust Password Safe | Read target credentials from BeyondTrust Password Safe at deploy time, using its managed-account API with API-key or OAuth authentication. | Planned |
Planned platform capabilities
Bigger platform features that change how clients and users interact with CertAutoPilot.
| Capability | What it will do | Status |
|---|---|---|
| ACME server / broker mode | Let CertAutoPilot act as an ACME CA of its own for internal clients: any ACME client (cert-manager, Caddy, Traefik, certbot, …) enrolls directly against CertAutoPilot, which brokers the request to a backing issuer (AD CS, Vault PKI, or a public CA) and handles renewal. Turns CertAutoPilot into an internal ACME gateway — services auto-enroll without a per-target distribution config. | Planned |
Planned authentication (SSO)
| Method | What it will do | Status |
|---|---|---|
| OIDC / OAuth2 SSO | Sign in with an enterprise IdP (Okta, Microsoft Entra ID / Azure AD, Ping, …) over OpenID Connect, with role/group mapping. | Planned |
| SAML 2.0 SSO | SAML 2.0 federation for IdPs that speak SAML, with attribute/group → role mapping. | Planned |
Today CertAutoPilot supports local accounts and LDAP; SSO is the most-requested enterprise authentication addition.
How targets get onboarded
Every new target follows the same pattern already used by the shipped modules: you define a target (connection details), attach a credential, wire a module config, and from then on renewals distribute automatically. Discovery can inventory where certs already live to help you plan which targets to create — see the difference between Discovery (find/inventory, read-only) and Distribution (deploy to configured targets).
Suggest / prioritize
Need a target, issuer, or integration that isn't here yet? Let us know — the module system is designed to add targets without touching the core, so new integrations land quickly.