Overview#
The Secrets Management Platform provides secure, encrypted storage for service credentials, certificates, and other sensitive configuration data across your organisation. Designed with a zero-trust architecture, it ensures secrets are protected at rest and in transit with strict tenant isolation across all multi-tenant deployments.
An operations team provisioning a new tenant needs to configure service credentials for five external intelligence feeds, a database credential, and webhook signing secrets for three integrations. Storing those values in environment variables or configuration files creates audit gaps and rotation headaches. A departing team member who had access to those files becomes a security liability. The Secrets Management Platform centralises that storage, enforces rotation automatically, and records every access event so the security team always knows who retrieved what and when.
Key Features#
- Encrypted storage for service credentials and tokens with zero-trust architecture
- Envelope encryption for customer-held secrets, with webhook signing secrets, data-source connector credentials, and cloud API tokens encrypted at rest under platform-managed keys and decrypted only at the moment of use
- Dedicated derived encryption keys for stored cloud API tokens, so credentials for billing and AI services are protected under their own key material rather than a shared key
- Production start-up validation that rejects hardcoded, placeholder, or missing secrets and enforces a character-diversity entropy floor on core secrets before a service is allowed to boot
- Fail-closed pseudonymisation keys: the pseudonymisation vault refuses to operate without its key present, and re-identification data sits behind a keyed reverse index so it is never stored in a linkable form
- Keyed digests in place of raw tokens for cache lookups, so refresh tokens are never used directly as cache keys
- Credential-free compliance evidence generation, so evidence packages shared with external auditors never capture live administrative credentials in recorded commands, logs, or index files
- Automatic secret rotation with zero-downtime updates, keeping services running during credential refresh
- Comprehensive audit logging for all secret access, recording user, time, and context for every retrieval
- Per-tenant isolation ensuring complete data separation between organisations
- Role-based access control for secret management, limiting who can read, write, and rotate each secret type
- Integration with external key management systems for organisations with existing KMS infrastructure
- Version history and rollback support for rapid recovery when a rotation causes an unexpected issue
Use Cases#
Third-Party API Integration#
Store and manage service credentials for external services such as intelligence data feeds, notification providers, and analytics platforms. Because connector credentials are envelope-encrypted under platform-managed keys, a leak of the underlying record store alone cannot expose them. Rotation policies ensure credentials are refreshed on a regular schedule, and audit trails satisfy compliance requirements for regulated data sources.
Webhook Authentication#
Manage signing secrets used to verify inbound and outbound webhook traffic. Signing secrets for incident notification webhooks are held encrypted at rest and decrypted only at send time, and keys can be rotated seamlessly without disrupting active integrations or requiring coordinated deployments across connected systems.
Database Credential Management#
Centralise storage of database passwords and connection credentials. Enforce periodic rotation, monitor access patterns through audit logs, and revoke credentials immediately when a security concern arises.
Certificate and Token Lifecycle#
Track expiry dates for certificates and long-lived tokens. Receive notifications before expiry and use automatic renewal workflows to prevent outages caused by expired credentials.
Compliance Evidence Sharing#
Generate audit evidence packages for external assessors and regulators without embedding live credentials. Credentials used during evidence-pack generation pass through a protected channel that never appears in recorded command lines, logs, or index files, so archived packs remain complete and auditable while staying safe to share externally.
Pseudonymised Data Protection#
Meet data-protection requirements for pseudonymised health and identity datasets. The pseudonymisation vault fails closed in production if its key is unset, rather than degrading to a predictable default, and its keyed reverse index ensures re-identification data is never held in a linkable form.
Open Standards#
- AES-256-GCM (NIST FIPS 197 / SP 800-38D): All secrets are encrypted at rest using 256-bit AES in Galois/Counter Mode, with per-secret Additional Authenticated Data binding the ciphertext to a specific tenant and record so encrypted blobs cannot be transplanted.
- HMAC-SHA-256 (RFC 2104 / FIPS 198-1): Secret integrity hashes and webhook signing secrets are generated and verified using HMAC with SHA-256, with SHA-256 (FIPS 180-4) also used for per-value integrity fingerprints stored alongside each encrypted blob.
- JSON Web Token (RFC 7519): Service-to-service calls to the secrets store are authenticated with signed JWTs; the platform also stores and rotates JWT signing secrets as a named secret type.
- PKCS#11 (OASIS): The encryption layer supports Hardware Security Module key wrapping via the PKCS#11 interface, allowing organisations to keep master key-encryption keys in a certified HSM rather than in software.
- FIPS 140-2: The encryption module is designed to operate in a FIPS 140-2 compliant mode, using validated cryptographic primitives throughout the key management and secret storage pipeline.
- OAuth 2.0 (RFC 6749): OAuth tokens are a recognised first-class secret type within the platform, stored with the same encryption, rotation scheduling, and audit logging as other credential classes.
Last Reviewed: 2026-07-16 Last Updated: 2026-07-16