Service — Secrets Management
A hardcoded API key is a password nobody rotates
Secrets management stores, rotates and controls the non-human credentials your applications depend on: API keys, certificates, database passwords, tokens and SSH keys. Kommando centralises them in a vault, rotates them automatically, and gets them out of your code, delivered on CyberArk across the Nordics.
Start with a discovery scan: see where your secrets actually live before you change anything.
- 29 million secrets were pushed to public GitHub in 2025
- Most leaked keys never rotate, so they keep working for years
- AI-assisted commits leak secrets at twice the rate
What is secrets management?
Giving every machine credential a home and a lifecycle
Secrets management is the practice of securely storing, rotating and controlling access to the non-human credentials that applications use: API keys, certificates, database passwords, tokens and SSH keys. Instead of sitting hardcoded in source code and config files, secrets live in a central vault with least-privilege access, automatic rotation and a full audit trail, and applications retrieve them at runtime.
Every application holds credentials, and there are far more of them than there are human passwords. A microservice needs a database password. A CI/CD pipeline needs a cloud access key. A script needs an API token.
The problem is where they end up: pasted into code, checked into Git, dropped into environment files, shared in chat, and copied between environments. Once a secret is in a repository, it’s effectively public to anyone who gets in, and it usually outlives the person who created it.
Secrets management fixes this by centralising credentials in a vault, encrypting them at rest and in transit, controlling who and what can retrieve them, rotating them automatically, and logging every access. According to Wiz, the core of any approach is centralising secrets, enforcing least privilege, automating rotation, and removing hardcoded credentials from source code.
- API keys & tokens
- TLS & other certificates
- Database passwords
- SSH keys
- CI/CD & cloud credentials
vs Password management
Secrets management vs privileged password management
They sound similar and often live in the same platform, but they solve different problems. Privileged password management secures the credentials people use. Secrets management secures the credentials machines use. Most organisations need both.
| Privileged password management | Secrets management | |
|---|---|---|
| Protects | Human privileged accounts (admins, root, domain admin) | Non-human credentials used by applications and machines |
| Examples | A DBA's admin login, a domain admin account | An API key, a TLS certificate, a CI/CD token |
| Accessed by | People, through a vault and session | Applications and pipelines, at runtime |
| Core risk | A stolen admin password | A hardcoded key leaked in a repo |
| Typical scale | Hundreds of accounts | Tens of thousands of secrets |
The platform
The six capabilities of secrets management
Centralized secret storage (the vault)
One encrypted, hardened store for every secret, instead of dozens of scattered copies. A single source of truth means access can be controlled, rotation can be automated, and you actually know what secrets exist. Common vaults include CyberArk, HashiCorp Vault, AWS Secrets Manager and Azure Key Vault.
Access control & least privilege
Every application, pipeline and person gets access only to the secrets it needs, and nothing else. A compromised service should be able to reach its own database password, not the entire estate. Machine identity is authenticated before any secret is handed over.
Automated rotation & expiry
Secrets are changed automatically on a schedule, and short-lived credentials expire on their own. Manual rotation is the step everyone skips, which is why so many leaked keys still work years later. Automation shrinks the window a stolen secret is useful.
Eliminating hardcoded secrets
The goal is simple: no secret in source code, config files or scripts, ever. Applications retrieve secrets from the vault at runtime, and scanning catches any that slip back into a repository. This is the single highest-impact change most organisations can make.
DevOps & CI/CD integration
Secrets management only works if developers will actually use it. That means native integration with the pipelines, orchestration and cloud platforms your teams already run, so fetching a secret is easier than hardcoding one.
Logging & audit
Every request for every secret is logged: who or what asked, when, and whether it was granted. When a key leaks or an auditor asks, you can see exactly where a secret has been used, and revoke it with confidence.
Why now
Why secrets management matters now
Secrets used to be a developer’s private problem. Then two things happened: there are far more secrets, and they leak far more easily.
The scale exploded. GitGuardian’s State of Secrets Sprawl 2026 found 29 million hardcoded secrets pushed to public GitHub in 2025 alone, a 34% jump year over year. Internal repositories are worse: 32% contain at least one hardcoded secret, and those are the CI/CD tokens and cloud keys attackers want most.
AI made it faster, and leaks linger. AI-assisted commits leak secrets at more than twice the rate of human-only ones, and 64% of secrets exposed in 2022 were still valid in 2026. A key that never rotates is a key an attacker can use for years, which is why credential abuse accounted for 22% of breaches in the 2025 Verizon DBIR.
hardcoded secrets pushed to public GitHub in 2025 (GitGuardian)
of secrets exposed in 2022 were still valid in 2026
AI-assisted commits leak secrets at twice the rate of human-only
By sector
Secrets management by sector
The exposure is universal, but the pressure lands differently.
Financial services
Regulation (DORA, PCI DSS) and heavy audit requirements make provable control over machine credentials non-negotiable. This is where “prove no key is hardcoded” moves from good practice to a formal requirement.
Technology & SaaS
Developer-heavy, cloud-native, pipeline-everything. The secret sprawl is largest here, and so is the payoff from getting rotation and vault integration right.
Healthcare
Patient data under GDPR flows through integrations and APIs, each with its own credential. Controlling and auditing those secrets is part of protecting the data behind them.
Public sector
Legacy systems, long-lived credentials and slow change combine into secrets that were set once and never touched. Bringing them into a vault is often the first real inventory anyone has done.
Our approach
How Kommando delivers secrets management
Discovery
We scan code, pipelines, config and infrastructure to find where secrets actually live. It’s always more places than expected, and the first inventory is usually the most valuable deliverable.
Design
Vault architecture, access policies, rotation schedules and the integration model that fits how your teams build, often alongside CyberArk PAM where privileged accounts are in scope too.
Implementation
Secrets migrated into the vault, applications integrated to fetch at runtime, and hardcoded credentials removed and revoked, starting with the highest-risk keys.
Managed services
We run and extend the platform, keep rotation healthy, and add scanning so secrets don’t creep back into repositories.
The hardest part isn't the vault. It's changing how applications get their credentials, and making the vault so easy that developers stop hardcoding on their own.
A note on what secrets management doesn't fix
A vault doesn't help if nobody fetches from it. The hardest part of secrets management isn't the platform, it's changing how applications get their credentials, and getting developers to stop hardcoding because the vault is genuinely easier to use. We design for adoption, because a vault that teams route around is just an expensive password file.
Frequently asked questions
Questions we actually get
What is secrets management?
Secrets management is the practice of securely storing, rotating and controlling access to non-human credentials such as API keys, certificates, database passwords, tokens and SSH keys. Instead of living hardcoded in source code and config files, secrets are held in a central vault with least-privilege access, automatic rotation and a full audit trail, and applications retrieve them at runtime.
What is the difference between secrets management and privileged password management?
Privileged password management secures the credentials people use, such as admin and root accounts, usually through a vault and monitored sessions. Secrets management secures the credentials machines use, such as API keys and certificates, retrieved by applications at runtime. Both are often delivered on the same platform, and most organisations need both.
What is secrets sprawl?
Secrets sprawl is the uncontrolled spread of credentials across code repositories, config files, chat tools, CI/CD systems and cloud platforms. It happens because secrets are easy to copy and hard to track. GitGuardian found 29 million hardcoded secrets pushed to public GitHub in 2025 alone, and internal repositories are worse.
What is a secrets vault?
A secrets vault is an encrypted, hardened store that holds credentials centrally, controls who and what can retrieve them, rotates them automatically and logs every access. Common enterprise vaults include CyberArk, HashiCorp Vault, AWS Secrets Manager and Azure Key Vault.
How does secret rotation work?
Secret rotation replaces a credential with a new one on a set schedule or on demand, and updates the systems that use it automatically. Short-lived secrets can expire on their own after minutes or hours. Because manual rotation is so often skipped, automation is what actually shrinks the window a stolen secret stays useful.
What is vaultless secrets management?
Vaultless approaches issue short-lived, just-in-time credentials instead of storing long-lived secrets in a vault, which suits ephemeral and cloud-native workloads. In practice most organisations use both models: a vault for long-lived secrets and just-in-time issuance where infrastructure is short-lived. We help you choose the right mix.
How is secrets management related to PAM?
Secrets management and Privileged Access Management (PAM) are closely related and often share a platform. PAM focuses on privileged human accounts; secrets management focuses on the machine credentials applications use. Together they cover both sides of privileged access, human and non-human.
Which secrets management platform should we use?
The right platform depends on your stack, but CyberArk is the platform we most often implement for enterprise secrets management in the Nordics, and it integrates with the PAM most organisations already run. More important than the product is the design: the vault architecture, the rotation policy, and how easily developers can adopt it.
Do you offer managed services for secrets management?
Yes. Many organisations stand up a vault and then struggle to keep rotation healthy and stop secrets creeping back into code. We run and extend the platform after go-live, including ongoing secret scanning, which is often more realistic than staffing it in-house.
Next step
Find out where your secrets actually live
A discovery scan finds the hardcoded keys, tokens and certificates across your code, pipelines and infrastructure, usually in more places than anyone expects. If you want to talk through where you’re at, we’re happy to help.
- Full inventory of secrets across your estate
- Remediation plan ordered by risk
- Delivered locally in Norway, Sweden and Denmark
Oslo · Gothenburg · Stockholm · Copenhagen
