India’s Leading Domain & Web Hosting Provider
Secrets & Key Management: Vaults, Rotation, KMS and HSM Design
Secrets and key management covers how applications store and rotate credentials such as database passwords and API keys, and how encryption keys are created, protected, rotated and revoked. NTSPL removes secrets from code and config into managed vaults with automated rotation, and designs KMS key hierarchies, HSM-backed keys and BYOK or HYOK options for Indian SaaS, fintech and regulated firms.
Delivered on
In scope
Hard-Coded Credentials and Flat Key Sprawl: The Two Hidden Liabilities
Secret scanners run on a typical five-year-old codebase find hundreds of credentials: database passwords in properties files, payment gateway keys in environment variables baked into images, partner API tokens pasted into CI variables, and the same admin password reused across environments. Rotation happens only after an incident because nobody knows what would break. On the encryption side, keys are created ad hoc, one per resource or one for everything, with key administrators who can also read the data, and enterprise customers now ask for keys they control.
NTSPL works in two tracks. The secrets track scans repositories, images and pipelines, ranks every credential by blast radius, moves it into Secrets Manager, Key Vault or Secret Manager, wires applications to fetch it at runtime through workload identity and turns on rotation, starting with databases where managed rotation exists. The keys track designs a hierarchy by environment and data class, separates key and data administrators, and adds HSM or external key options only where a regulator or customer requires them.
Indicators That Secrets and Keys Need a Managed Lifecycle
Signals you need Secrets & Key Management
- A secret scan finds more than 50 live credentials in repositories, images or CI variables
- Database or partner API passwords have not rotated in over a year because the impact is unknown
- One encryption key protects many unrelated datasets, or key admins can also read the data
- Enterprise or banking customers ask for customer-managed or bring-your-own keys
- A leaked key incident took more than a day to rotate across all environments
When to choose something else
- You first need to know where sensitive data sits and whether it is encrypted at all: start with Data Security & Encryption.
- Human administrator access and standing privileges are the problem rather than application credentials: see Identity & Access Management.
Vault Migration, Rotation, Key Hierarchy and HSM Options
Secret discovery
Scan Git history, container images, CI/CD variables, configuration stores and VM user data with Gitleaks, TruffleHog or native secret scanning, and rank findings by blast radius.
Vault migration
Move credentials into managed vaults with one path convention per environment, accessed at runtime through instance roles, managed identities or Workload Identity.
Rotation automation
Enable managed rotation for databases, build rotation functions for partner and payment API keys, and schedule certificate renewal.
Key hierarchy
Design customer-managed keys by environment, application and data class, with separate key administrator and key user roles and rotation settings.
HSM and external keys
Deploy dedicated or managed HSMs, BYOK import or external key managers where regulation or contracts require control beyond standard KMS.
Discover, Vault, Rotate: Secrets Lifecycle and Key Hierarchy Design
Runtime Secret Retrieval and Tiered Key Hierarchy
Applications authenticate with platform identities and fetch secrets from a vault at runtime, while rotation functions change credentials on a schedule without redeploys. Encryption keys are arranged by environment and data class, with key administrators separated from data users and HSM or external keys reserved for restricted data.
Select any component
Runtime Secret Retrieval and Tiered Key Hierarchy: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Secrets Manager, Key Vault and Secret Manager with Their KMS Options
Secrets Manager offers managed rotation for RDS, Aurora and Redshift; KMS keys can be scheduled for deletion only after a 7-30 day waiting period.
Key Vault publishes near-expiry events to Event Grid, which triggers rotation functions; Managed HSM gives single-tenant, HSM-backed key pools with local RBAC.
Secret Manager rotation schedules publish Pub/Sub notifications that a Cloud Run function acts on; Cloud EKM keeps key material outside Google with a supported partner.
Rotation Intervals, Key Granularity and BYOK or HYOK Choices
Rotation intervals
Rotate database credentials every 30-90 days through managed rotation, payment and partner API keys every 90-180 days or as the partner allows, and certificates automatically 30 days before expiry. Rotate immediately on any confirmed exposure. Faster rotation is pointless if applications cache secrets for days; set client cache refresh to 15 minutes or less first.
Key granularity
Create keys per environment, application and data class, not per resource. A mid-size estate typically needs 20-60 customer-managed keys. One key for everything means a single policy mistake exposes all data; one key per bucket creates hundreds of policies nobody reviews. Use separate keys for logs and backups so their access can be restricted differently.
When to use HSM or external keys
Standard cloud KMS uses FIPS-validated HSMs and suits most needs. Choose single-tenant HSMs when a regulator, card scheme or contract requires dedicated hardware, or for payment key operations. Choose BYOK or external key managers only when a customer insists on revocation control; they add latency, cost and an availability dependency you must design for.
Vault topology
Use one vault or secret namespace per environment and application group, in the same region as the workload, for example Mumbai with a replica in Hyderabad. Avoid a single global vault that every workload reads; it becomes a blast-radius and throttling risk. Replicate secrets across regions for DR, and test that DR workloads can read them.
Vaulting Hundreds of Secrets Without Breaking Production
Secret discovery and triage
Scan repositories, images and pipelines, verify which secrets are live and rank by blast radius.
Emergency rotation of exposed secrets
Rotate any credential found in public repositories or shared with ex-vendors immediately.
Vault migration by application
Move secrets into vaults application by application with runtime retrieval and no restarts.
Rotation automation
Enable managed rotation for databases and build functions for partner keys and certificates.
Key hierarchy and HSM options
Deploy customer-managed key structure, separation of duties and any HSM or BYOK tier required.
What you receive
Secret Hygiene and Key Governance Measures
| KPI | Typical target |
|---|---|
| Live secrets in code, images or CI variables | Zero |
| Vaulted secrets with automated rotation | 80% or more |
| Time to rotate a credential across all environments | Under 1 hour |
| Keys with combined admin and data-use permissions | Zero |
Rotation Outages, Key Deletion and Vault Single Points of Failure
| Risk | How NTSPL prevents it |
|---|---|
| Rotation breaks applications that cache credentials | Dual-credential rotation and 15-minute client refresh are tested in staging before production rotation. |
| A key is deleted or disabled and data becomes unrecoverable | Deletion protection, maximum waiting periods and alerts on any schedule-deletion or disable call. |
| External key manager outage takes applications down | Redundant EKM endpoints, documented customer responsibilities and failover tests before go-live. |
Cloud-native secrets managers or HashiCorp Vault?
For workloads on one cloud, use the native manager. AWS Secrets Manager, Azure Key Vault and Google Secret Manager integrate with platform identities, managed rotation, KMS and audit logs with no servers to run. HashiCorp Vault is the better fit if you run several clouds plus on-premises and want one secrets API, need dynamic short-lived database credentials across many engines, or already operate Vault well. Vault Enterprise or the HCP-managed offering adds licence cost, and self-hosted Vault becomes a critical service you must patch, back up and keep highly available. Do not adopt it just to avoid three consoles.
Key facts: Secrets & Key Management
Secrets & Key Management in Practice
2 Secrets & Key Management scenarios, from Ad-tech (programmatic demand-side platform) and Legal-tech (contract lifecycle management SaaS), plus related platform case studies.
Ad-tech DSP vaults 340 hard-coded credentials and rotates exchange keys in minutes
Legal-tech SaaS offers per-tenant BYOK on Managed HSM and wins two bank legal teams
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Three directories become one: identity consolidation after two acquisitions
Secrets & Key Management: Frequently Asked Questions
How much does a secrets and key management programme cost?
For 20-60 applications, NTSPL's engagement typically runs INR 10-20 lakh over 10-12 weeks. Vault charges are modest, usually a small monthly fee per secret plus API calls, so most estates spend INR 10,000-60,000 a month. Dedicated HSMs are a significant addition, often several lakh a month per cluster.
What should we do first if secrets were pushed to a public repository?
Rotate the credential immediately; deleting the commit does not help because forks and scrapers copy it within minutes. Then check access logs for use of that credential since the commit time, scope the impact and, if personal data or financial systems were reachable, assess CERT-In and DPDP reporting duties.
Do Indian regulators require HSMs?
Regulators generally require strong key management and protection of cryptographic keys rather than naming a specific product. Card scheme rules, PCI requirements and some contracts with banks call for HSM-protected or dedicated hardware for certain keys. We map each requirement to the minimum control that satisfies it.
What is the difference between BYOK and HYOK?
With BYOK you generate key material in your own HSM and import it into the cloud KMS, which then holds and uses it. With hold-your-own-key or external key management, key material stays outside the provider and each use is a call to your key manager, so revocation is immediate but availability depends on you.
Can rotation happen without downtime?
Yes, if the pattern is right. Managed database rotation and our rotation functions create a new credential while the old one stays valid, applications refresh from the vault within minutes, and the old credential is revoked only after all instances use the new one.
How do you stop new secrets entering code?
Pre-commit hooks and pipeline scanning block commits and builds containing secrets, platform secret scanning watches repositories continuously, and developers get vault paths and SDK patterns that make the right approach easier than hard-coding. Any blocked secret is treated as exposed and rotated.