Credentials & Key Rotation
This page covers the operational side of managing your credentials over time: what to rotate, when, and how the pieces fit together. For the initial issuance process, see Onboarding Overview & Checklist and mTLS Certificates & CSR.
Your credential inventory
As covered in Program Architecture and Authentication & Environments, each environment (staging, production) and each scope (Tenant, Program) has its own independent set of credentials:
| Credential | Scope | Lifetime | Rotation trigger |
|---|---|---|---|
| mTLS client certificate | Tenant or Program, per environment | 90 days | Expiry reminders (30/15/5 days) — see below |
X-API-Key | Tenant or Program, per environment | No fixed expiry | Periodic rotation as a security best practice, or immediately on suspected compromise |
Certificates and API keys rotate independently of each other — renewing your certificate does not require (or cause) a new API key, and vice versa. Track both separately. A simple internal register — one row per environment/scope, with issue date, expiry date (for certificates), and last-rotated date (for API keys) — is enough for most integrations.
Certificate renewal workflow
Certificates are valid for 90 days, with expiry reminders at 30, 15, and 5 days before expiry (delivered as described in Webhooks & Callback Notifications). The recommended workflow, starting from the 30-day reminder:
sequenceDiagram
participant Axys
participant You
Note over Axys,You: T-30 days
Axys->>You: Reminder — certificate expires in 30 days
You->>You: Generate new key pair + CSR
You->>Axys: Submit new CSR
Axys->>You: New certificate issued (~24h)
You->>You: Deploy new certificate alongside the old one (overlap)
You->>Axys: Test request using the new certificate
Axys->>You: 200 OK
You->>You: Retire the old certificate and private key
Note over Axys,You: T-0 — old certificate would have expired
Because the old certificate remains valid throughout the overlap period, there's no requirement to synchronize the cutover precisely — you can deploy the new certificate, verify it works, and retire the old one on your own schedule, as long as it's comfortably before expiry. For the step-by-step commands, see Rotate mTLS Certificates.
If a certificate lapses without renewal, every request using it will fail at the TLS handshake — before your
X-API-Keyis even checked, and before any application-level error handling on your side can run. Treat the 30-day reminder as the trigger to start renewal, not the deadline to finish it.
API key rotation
Self-service API key rotation is part of the platform's Account Management tenant-management capabilities. API key issuance and rotation are handled through your Axys onboarding/account contact.
When rotating an API key (whether on a routine schedule or in response to a suspected compromise):
- Request a new API key for the affected scope (Tenant or Program) and environment.
- Update your application's configuration/secrets store with the new key.
- Deploy and verify the new key is working.
- Request revocation of the old key.
If you suspect a key has been compromised, treat steps 1 and 4 as urgent — request both the new key and the old key's revocation as part of the same request, rather than waiting for a routine rotation cycle.
Storage and access
Both credential types should live in a secrets manager appropriate to your infrastructure, loaded at runtime, and never committed to source control or embedded in client-side code. See Security Compliance & Data Protection for the platform's own custody and key-management architecture, and the broader principle-of-least-privilege guidance for your integration.
