[Developers]

Secrets Domain

A platform service needs to authenticate to an external threat intelligence feed. Rather than embedding the API key in environment variables or configuration files, the service retrieves it at runtime from the Secrets do

Category: Api DomainsLast Updated: Feb 23, 2026
api-domainscompliance

Overview#

A platform service needs to authenticate to an external threat intelligence feed. Rather than embedding the API key in environment variables or configuration files, the service retrieves it at runtime from the Secrets domain: encrypted, access-logged, and subject to a rotation schedule. When the key approaches its expiry date, the platform sends a notification before it causes an outage. After rotation, the new value is versioned so that if a rollback is needed, the previous credential is still available. The Secrets domain manages the complete lifecycle of sensitive credentials across the platform, from initial storage through access auditing, rotation tracking, and expiration monitoring.

Key Features#

  • Secure Storage: All secrets are encrypted at rest and accessible only through authenticated, authorised requests, ensuring sensitive credentials are protected throughout their lifecycle.

  • Multiple Secret Types: Manage a variety of credential types including API keys, database passwords, OAuth tokens, webhook secrets, certificates, and SSH keys with type-specific handling and validation.

  • Access Logging: Every secret access is recorded with a complete audit trail, providing visibility into who accessed what credentials and when for security monitoring and compliance.

  • Rotation Management: Track rotation schedules and expiration dates for all secrets, with alerts when credentials are approaching expiration to prevent service disruptions.

  • Version History: Maintain versioned records of secret values to support rollback scenarios and ensure continuity during credential rotation processes.

  • Expiration Monitoring: Automatically track expiration dates and generate notifications before secrets expire, reducing the risk of service outages due to stale credentials.

Use Cases#

Centralised secrets management is a requirement in any environment subject to security audits or compliance frameworks. Primary industries include financial services, healthcare, and government and public safety.

  • API Credential Management: Securely store and distribute API keys and tokens used by platform services to communicate with external providers and data sources.

  • Certificate Lifecycle: Manage SSL/TLS certificates and SSH keys with rotation tracking to ensure encrypted communications remain valid and uninterrupted.

  • Compliance Auditing: Demonstrate proper credential management practices to auditors with comprehensive access logs and rotation histories.

  • Credential Rotation: Plan and execute credential rotation across services with version management to ensure zero-downtime transitions.

Integration#

The Secrets domain supports secure operations across the platform:

  • Service Configuration: Platform services retrieve credentials securely at runtime
  • External Integrations: API credentials for third-party services are managed centrally
  • Audit and Compliance: Access logs contribute to the organisation's compliance posture
  • Alert System: Expiration warnings feed into the notification system

Open Standards#

  • AES-256-GCM (NIST SP 800-38D / FIPS 197): All secret values are encrypted at rest using AES-256-GCM authenticated encryption, with per-row Additional Authenticated Data (AAD) binding the ciphertext to its tenant and record identity to prevent cross-tenant ciphertext transplant.
  • PKCS#11 (OASIS / RSA Security): The encryption layer supports Hardware Security Module (HSM) key wrapping via PKCS#11, keeping the master Key-Encryption Key (KEK) non-extractable in hardware for regulated environments.
  • HMAC-SHA-256 (RFC 2104 / FIPS 198-1): SHA-256 digests are computed over each plaintext value on write and verified on read to detect storage tampering; HMAC-SHA-256 is also used for searchable blind-index derivation.
  • JSON Web Token (RFC 7519): Service-to-service requests to the encrypted secrets store are authorised with signed JWTs carrying scoped claims (middleware:secrets:read / middleware:secrets:write).
  • OAuth 2.0 (RFC 6749): The scoped bearer token model for inter-service authorisation follows OAuth 2.0 token grant and audience conventions, enforced on every secrets store request.
  • GraphQL: All secret lifecycle operations, create, read, update, delete, rotate, and audit log retrieval, are exposed through a strongly typed GraphQL API.
  • RFC 4122 (UUID): Every secret record, access log entry, and rotation history entry is assigned a version-4 UUID as its stable identifier.

Last Reviewed: 2026-02-23 Last Updated: 2026-04-14

Ready to Build?

Get started with our APIs or contact our integration team for support.