Secrets management using key vaults and HSMs: a practical guide for UK SMEs

For many UK SMEs, secrets management starts as a simple problem and slowly becomes an operational risk. A team needs an API key, a database password, a certificate, or an encryption key. The quickest route is often to place it in a configuration file, a build variable, or a shared spreadsheet. That may feel efficient at first, but it creates avoidable exposure as systems grow, teams change, and delivery becomes more automated.

Secrets management is the discipline of storing, accessing, rotating, and monitoring sensitive values in a controlled way. In practice, that means reducing where secrets live, limiting who can see them, and making sure applications retrieve them only when needed. Two common tools help with this: key vaults and hardware security modules, often called HSMs.

This article explains what they do, when to use each one, and how smaller teams can introduce them without making delivery unnecessarily complex.

Why secrets management matters in everyday software delivery

What counts as a secret, and why hard-coded credentials create avoidable risk

A secret is any value that should not be widely known or easily reused by an unauthorised person. Common examples include passwords, API keys, tokens, private keys, database credentials, and signing keys. Some of these unlock systems directly. Others allow an attacker to impersonate a service, read data, or make trusted changes.

Hard-coded credentials create risk because they are difficult to control once they spread. A secret placed in source code can be copied into a branch, a test environment, a build log, a support ticket, or a developer laptop. Even if the code is later changed, old copies may still exist in backups or commit history. If the secret is reused across systems, the impact can be wider than expected.

For SMEs, the issue is usually not one dramatic failure. It is the gradual accumulation of small exposures. A few shared passwords, a handful of long-lived tokens, and some environment variables that are visible to more people than intended can become a weak point in an otherwise sensible security setup.

Where SMEs commonly lose control of secrets across development, testing, and operations

Secrets often leak through ordinary working practices rather than deliberate misuse. Common examples include:

• Developers storing credentials in local configuration files.
• Test environments using production-like secrets because they are easier to copy.
• Build pipelines exposing values in logs or job output.
• Operations teams sharing access to a single admin account.
• Temporary fixes becoming permanent because no one owns the cleanup.

These patterns are understandable in small teams, especially where people wear several hats. The challenge is that convenience tends to win unless the secure option is built into the normal workflow. That is where key vaults and HSMs become useful.

What key vaults and HSMs do

Key vaults explained in plain English

A key vault is a controlled store for secrets. Think of it as a secured service that keeps sensitive values out of code, files, and shared documents. Applications and approved users can retrieve a secret at runtime, usually through an authenticated request and with permission checks in place.

Key vaults are useful because they centralise control. Instead of copying a password into multiple places, you store it once and manage access from one location. That makes it easier to rotate credentials, revoke access, and see who accessed what. Many vaults also support versioning, audit logs, and integration with deployment tools.

In practical terms, a vault helps answer three questions: where is the secret stored, who can access it, and how do we know when it was used?

Hardware security modules explained in plain English

An HSM is a dedicated piece of hardware designed to protect cryptographic keys. Cryptographic keys are the values used to encrypt data, decrypt it, or create digital signatures. The key difference with an HSM is that the key is generated and used inside protected hardware, rather than being freely copied around a server or application.

That matters when the key itself is especially sensitive. If an attacker gets hold of a normal server, they may be able to extract keys stored in software. An HSM is designed to make that much harder. It can also enforce controls around key generation, usage, and export, depending on the design and configuration.

For SMEs, an HSM is not usually the first thing to deploy for every secret. It is more often used where the business impact of key compromise is higher, or where there is a need for stronger protection of signing or encryption keys.

When to use a key vault, an HSM, or both

Choosing based on sensitivity, operational complexity, and business risk

The right choice depends on what you are protecting and how the system is used. A key vault is usually the better starting point for application secrets such as database passwords, API tokens, and service credentials. It is easier to adopt, simpler to integrate, and often enough to remove the worst habits such as hard-coding secrets in code.

An HSM becomes more relevant when the key material itself needs stronger protection. That may be because the key is used to sign software, protect high-value data, or support a trust function that would be difficult to replace if compromised. HSMs can also help where there are strict internal requirements for key handling, separation of duties, or reduced key export.

Some organisations use both. A vault may store operational secrets and manage access for applications, while an HSM protects the most sensitive cryptographic keys behind the scenes. That combination can be sensible, but it should be driven by risk rather than by the desire to use more technology.

Typical use cases for application secrets, encryption keys, and signing keys

As a rule of thumb:

• Application secrets such as database credentials, third-party API keys, and service tokens usually belong in a key vault.
• Encryption keys may be stored in a vault or protected by an HSM, depending on how sensitive the data is and how the key is used.
• Signing keys used for code signing, document signing, or trust decisions are often stronger candidates for HSM-backed protection.

The more damaging it would be for a key to be copied, the more value there is in stronger protection. The more frequently a secret changes or needs to be consumed by applications, the more important ease of automation becomes.

How to design a practical secrets management approach

Separating secrets by environment and limiting who can access them

One of the simplest improvements is to separate secrets by environment. Development, test, staging, and production should not share the same credentials unless there is a very good reason. If a non-production environment is compromised, production should not automatically be at risk.

Access should also be limited by role. Developers may need access to some non-production secrets, but they should not automatically have access to live customer data credentials. Operations staff may need production access, but that does not mean every team member needs the same level of privilege. The aim is to reduce standing access, which means access that exists all the time rather than only when needed.

For SMEs, this often means defining a small number of access groups, documenting what each group can reach, and reviewing those permissions regularly. It does not need to be elaborate. It does need to be clear.

Reducing exposure through rotation, short-lived credentials, and least privilege

Rotation means changing secrets on a planned basis. If a secret is exposed, rotation limits how long it remains useful. Even when there is no known issue, rotation can reduce the value of old credentials that may have been copied into places they should not be.

Short-lived credentials are even better where they are practical. Instead of issuing a password that stays valid for months, the system issues a token that expires quickly. That reduces the window of opportunity if the token is intercepted. It also supports modern automation, where applications request access when they need it rather than storing a long-lived secret indefinitely.

Least privilege means giving each user or service only the access it needs to do its job. A service that reads one database table should not have broad administrative rights. A pipeline that deploys to a test environment should not be able to modify production secrets. These controls reduce the blast radius if something goes wrong.

Integrating secrets management into development and deployment

Keeping secrets out of source code, build logs, and pipeline variables

Good secrets management starts with keeping secrets out of places that are easy to copy. Source code repositories should not contain live secrets. Build logs should not print them. Pipeline variables should not become a hidden store of long-lived credentials that everyone can inherit by default.

It helps to treat the build and deployment process as part of the security design, not just a delivery mechanism. If a pipeline needs access to a secret, ask what it needs, when it needs it, and whether that access can be narrowed. In many cases, the answer is to fetch the secret only at deployment or runtime, rather than storing it in the pipeline itself.

Teams should also check for accidental leakage in commit history, configuration templates, and support artefacts. A vault does not remove the need for good hygiene elsewhere. It simply gives you a better place to keep the live value.

Using automation to retrieve secrets safely at runtime

The most sustainable pattern for smaller teams is usually to let applications retrieve secrets automatically when they start or when they need them. That avoids manual copying and reduces the temptation to keep credentials in local files.

In practice, this means the application or deployment identity authenticates to the vault, proves it is allowed to access a specific secret, and receives the value securely. The secret is then used in memory rather than written to disk wherever possible. If the secret must be cached, the cache should be short-lived and protected.

Automation should be designed carefully. The goal is not to make everything invisible. It is to make the secure path the easiest path. If developers have to jump through too many hoops, they will work around the process. A simple, well-documented retrieval pattern is usually better than a complex one that only a few people understand.

Operational controls that make the approach sustainable

Monitoring access, reviewing permissions, and handling exceptions

Once secrets are in a vault or protected by an HSM, the work is not finished. You still need to know who accessed what, whether access was expected, and whether permissions remain appropriate.

Monitoring does not need to be noisy. For an SME, the most useful approach is often to alert on unusual access patterns, failed authentication attempts, changes to key permissions, and unexpected secret retrieval from a new system or location. Regular review of access lists is also important, especially when staff change roles or leave the business.

Exceptions should be time-limited and recorded. If a team needs temporary access for a migration or incident response activity, that access should have an owner, a reason, and an end date. Otherwise, temporary access tends to become permanent by accident.

Planning for backup, recovery, and key lifecycle changes

Secrets management also needs a recovery plan. If a vault becomes unavailable, how will critical services continue? If a key is rotated, how will dependent systems be updated? If an HSM-backed key is replaced, what is the process for reissuing certificates or re-encrypting data where needed?

These are not edge cases. They are part of normal operations. A practical design should include backup and recovery arrangements, tested restoration steps, and a clear view of which systems depend on which secrets. Without that mapping, a simple key change can turn into an avoidable outage.

It is also worth planning for lifecycle changes. People leave, suppliers change, applications are retired, and environments are rebuilt. Secrets should be removed when they are no longer needed. Old credentials that remain active after a system has been decommissioned are unnecessary exposure.

Common mistakes SMEs should avoid

Treating a vault as a silver bullet without access governance

A key vault is helpful, but it is not a complete security strategy. If too many people can access the vault, or if applications share broad permissions, the risk simply moves to a different place. The same is true for HSMs. Strong hardware protection does not help if the surrounding access model is weak.

Good governance still matters. That includes role-based access, approval for elevated permissions, logging, periodic review, and a clear owner for each secret or key. The technology supports the process, but it does not replace it.

Overcomplicating the design and creating fragile operational processes

Another common mistake is to design a system that is technically impressive but hard to operate. If every secret requires a bespoke workflow, teams may avoid using the system properly. If the process is too rigid, people may create workarounds that are less secure than the original problem.

For SMEs, the best design is usually the simplest one that reduces the biggest risks. Start with a small number of critical secrets, automate the common case, and keep the exception process manageable. A good solution should make it easier to do the right thing every day.

A simple implementation roadmap for smaller teams

Start with the highest-risk secrets and the most exposed systems

If you are starting from scratch, do not try to move everything at once. Begin with the secrets that would cause the most disruption if exposed. That often includes production database credentials, cloud access keys, customer-facing API tokens, and signing keys.

Next, look for the most exposed systems. Public-facing applications, shared build pipelines, and environments with broad access are usually the best places to start. Removing hard-coded secrets from those areas gives you a quick reduction in risk and builds momentum for the rest of the programme.

At this stage, it helps to document where each secret lives, who uses it, and how often it changes. You do not need a perfect inventory on day one, but you do need enough visibility to make sensible decisions.

Build a phased rollout that fits existing delivery processes

A phased rollout is usually more realistic than a big-bang change. A sensible sequence might be:

1. Identify the most sensitive secrets and remove any hard-coded copies.
2. Introduce a key vault for application secrets and shared credentials.
3. Separate secrets by environment and reduce standing access.
4. Automate runtime retrieval for key applications and pipelines.
5. Use HSM-backed protection for the most sensitive keys where the risk justifies it.
6. Review logging, monitoring, rotation, and recovery procedures.

The exact order will depend on your systems and team size. The important point is to make progress in manageable steps. A smaller organisation does not need a large platform team to improve secrets handling. It needs a clear approach, a few practical controls, and enough discipline to keep the process consistent.

Used well, key vaults and HSMs can reduce secret sprawl, limit unnecessary access, and make secure delivery easier to sustain. They work best when they are part of a broader operating model that includes access control, rotation, monitoring, and recovery planning. For UK SMEs, that combination is usually more valuable than any single product feature.

If you would like help shaping a practical secrets management approach that fits your development and operations model, speak to a consultant.

Frequently asked questions

What is the difference between a key vault and an HSM?

A key vault is a managed place to store and control access to secrets such as passwords, tokens, and some keys. An HSM is specialised hardware that protects cryptographic keys more strongly, especially where the key itself is highly sensitive. In simple terms, a vault helps you manage secrets well, while an HSM helps protect certain keys more robustly.

How can a small team introduce secrets management without slowing delivery?

Start with the most sensitive secrets, remove hard-coded values, and use a vault for runtime retrieval. Keep the process simple, automate the common cases, and limit access by role. Small teams usually get the best results by improving the highest-risk areas first rather than trying to redesign everything at once.

Further reading

Microsoft documentation on Azure Key Vault and Azure Managed HSM can be useful if you are comparing managed vault and HSM options in a cloud environment. The key point is to understand the operational differences before choosing a design.