EU Secrets Management: Why We Built SikkerKey in Europe

A European secrets manager, built and run inside the EU

SikkerKey is a European secrets manager. The company is Danish, the vault runs on dedicated bare-metal servers in Germany, and your secrets and the records around them are stored on EU infrastructure operated by an EU company. If you are an EU team looking for a secrets manager that keeps your credentials, your audit trail, and your machine identities under European jurisdiction, that is the product we set out to build.

This is not a compliance badge bolted onto a US platform. It is the starting position. A secrets manager holds the credentials that reach your databases, payment providers, cloud accounts, internal APIs, and production services, and it records who and what touched them. For a system that sensitive, where it lives and which law governs the company that runs it are not footnotes. They are among the first questions an EU buyer should ask, and we answer them precisely below, including the parts that are not purely European.

"Hosted in the EU" is not the same as data sovereignty

The phrase you see everywhere is "EU region." A non-EU platform runs a data center in Frankfurt or Dublin, labels it an EU region, and treats the residency question as answered. For a secrets manager, that answer is incomplete.

Three things decide whether your secrets layer is genuinely European, and only one of them is about where the servers sit:

• Where the data is stored. The encrypted secrets, the audit logs, the machine identities, and the account records, held inside the EU.
• Which law governs the company. A data center in the EU operated by a non-EU company is still operated by a company that answers to non-EU law. The location of the servers and the jurisdiction over the operator are separate questions.
• Who controls the vault. The system of record for your secrets, where they are stored and served and the company that decides who reaches them, is what an access demand would target. That should sit under EU jurisdiction.

Data residency answers the first point. Data sovereignty answers all three. For most products the gap between them is easy to paper over, because the data they hold is documents and records. For a secrets manager the gap is the whole game, because the thing being held is live production access. A leaked document is a bad day. Compelled disclosure of a production database credential is a breach of everything that credential reaches.

When we say SikkerKey is an EU-centered secrets manager, we mean those three: EU-stored data, a Danish company, and a vault no US entity controls.

Where your secrets live, and what touches the US

A vault is more than the secret values it stores. Every useful access decision produces metadata: which machine asked, which user granted, which IP the request came from, which project the secret belongs to, and whether the read was allowed or denied. Many products treat that metadata as an afterthought and scatter it across managed services in whatever region is convenient. For a secrets manager it is sensitive in its own right, and we keep it in the EU:

• Secrets are stored encrypted on dedicated servers in Germany. The keys that unlock them are held apart from the stored data, so the infrastructure holding an encrypted secret cannot read what is inside it.
• Audit logs, machine identities, account data, and session data are stored on that same EU infrastructure, not on third-party services abroad.
• Backups sit on a server we physically own and operate in Denmark, kept off any cloud and encrypted the same way live data is.
• IP intelligence runs locally. When SikkerKey needs to know which country or network a request came from, for an audit entry, an allowlist check, or a suspicious-access review, the lookup runs on our own servers against a local database. Your IP addresses are not sent to a third-party geolocation service to enrich a security event.

Now the part most EU positioning skips. Like essentially every web service, requests to SikkerKey reach us through a global edge for DNS, DDoS protection, and TLS, and that edge is run by a US company. Billing runs through a US payment processor that handles an email address and a subscription record, and never holds card data on our systems. Both are in our sub-processor register, and both operate under Standard Contractual Clauses and the EU-US Data Privacy Framework. Neither is the system of record for your secrets. Your vault, the secrets in it, the audit logs, and your machine keys are stored in the EU, by a Danish company, and no US provider holds them.

That is also the honest answer to the US CLOUD Act question. The CLOUD Act lets US authorities compel a company subject to US jurisdiction to produce data it holds. SikkerKey is a Danish company with no US parent or subsidiary, and your secrets are stored in the EU, so there is no US company holding your vault that could be ordered to surrender it. We do not claim more than that, and we would rather name the US providers we do use than imply a fully European stack we do not have.

We also run the vault on bare metal on purpose. A secrets manager is the system other systems trust, and the more managed services sit behind a single secret read, the more parties end up inside your risk review. Keeping the storage and serving path on dedicated infrastructure keeps it small enough to explain, and for a secrets manager an explainable boundary is a security property: you should be able to ask where your vault lives and get an answer that fits in a sentence.

How signed machine requests remove the bearer-token risk

Knowing where the vault runs answers one question. How a machine proves it is allowed to read a secret answers the other, and a strong residency story with weak machine authentication is still weak secrets management.

Most secrets managers hand a machine a token: a long string it stores and sends back on every request. Whoever holds the string is treated as the machine. Copy it out of an environment variable, a log line, or a crash dump, and it can be replayed from anywhere until someone notices and revokes it.

SikkerKey does not issue reusable tokens for secret reads. Every enrolled machine generates its own Ed25519 keypair, and the private key never leaves the machine. To read a secret, the machine signs the exact request it is making: the method, the path, a timestamp, a nonce, and a hash of the body. We verify the signature against the machine's registered public key, check the grant, apply policy, and record the read against that machine by name.

The failure mode changes completely. There is no standing credential to steal, because the signature proves possession of a private key without ever sending it, and it is valid only for the one request it signed. An attacker who scrapes a log or a memory dump finds nothing replayable. And because every read is tied to a real machine identity, the audit log answers incident questions in the terms you actually need: which machine, which secret, which IP, what time, and whether the request matched policy.

This is the design we keep coming back to, and we explain it in full in why we sign every secret request instead of handing out bearer tokens. It is also why the residency claim and the authentication claim reinforce each other here: the vault stays under a European company, and the right to read from it is enforced by cryptography you can inspect rather than by a token string that anyone holding it can use. You can see how the model works across cloud, on-premises, and CI machines on our machine authentication page.

What NIS2 asks of your secrets layer

If your organization falls under NIS2, your secrets layer is squarely in scope of its obligations. NIS2 (Directive (EU) 2022/2555) requires essential and important entities to manage cyber risk with proportionate measures, and Article 21 names several that a secrets manager touches directly: access control, the use of cryptography, supply-chain security, and incident handling. Member States were required to transpose it into national law by October 2024, and most now have.

SikkerKey supports those obligations rather than claiming to satisfy them for you, because compliance is an organization-wide responsibility that no single tool delivers. What we provide is the part a secrets layer is responsible for:

• Access control that is per secret and per machine, so a worker that can read one project's secret cannot read the whole vault.
• Cryptography in the request path itself, through signed machine authentication and encrypted storage.
• Supply-chain clarity, through a short, named sub-processor register and a path that does not fan your secret reads across a long chain of services.
• An audit trail built for the incident report. NIS2 puts you on a tight clock to report a significant incident. An audit log that names the machine, the secret, the IP, and the time, and shows whether the request matched policy, is what lets you answer "what was accessed" in hours instead of days.

Choosing an EU-established secrets vendor also keeps your own supply chain simpler to defend. Article 21 expects you to account for the security of your direct suppliers, and a secrets provider under EU jurisdiction is one less third-country dependency to assess and justify.

What DORA asks if you are a financial entity

If you are a financial entity in the EU, or you supply ICT services to one, DORA has applied since 17 January 2025, and it changes how you are expected to manage the systems you depend on. DORA (Regulation (EU) 2022/2554) centers on ICT risk management, and in particular on ICT third-party risk: you keep a register of your ICT providers, hold them to contractual and operational standards, and account for concentration and exit risk.

A secrets manager sits right on that surface, because it governs how machines and services reach credentials and keys. SikkerKey supports those requirements with per-secret access control, signed and attributable machine authentication, and audit logs designed for review. Just as important, choosing a secrets provider established in the EU keeps a sensitive dependency inside European jurisdiction, instead of adding a third-country ICT relationship that you then have to register, justify, and defend in your own DORA assessment.

We do not claim to make you DORA compliant. We are saying that for the slice of the regulation a secrets layer answers to, an EU-stored, EU-governed vault is the cleaner choice.

What every EU team should ask a secrets manager

These are the questions we think any EU team should put to a secrets manager, including ours. We built SikkerKey so the answers stay short and we can point you to where the proof lives.

• Where is the company established? An EU data center used by a non-EU company is a different procurement story than an EU company. Ours is Danish.
• Where are the secrets and the metadata stored? Not only the secret values, but the audit logs, machine names, project names, and IP addresses. Ours are stored in the EU.
• Are IP addresses sent to a third-party geolocation service for routine checks? If the product does geolocation or allowlist logic, ask whether it runs locally or calls out to a remote service. Ours runs locally.
• How does a machine authenticate? If the answer is a token, ask where it lives, how often it rotates, and whether it can be replayed from another host. Ours sign each request with a per-machine key that never leaves the machine.
• Can access be scoped to a single secret? Compliance language is no substitute for least privilege. A production worker should not be able to read the whole vault because it holds one grant.
• Can the audit log answer an incident quickly? During an incident you need to know which machine read which secret, from which IP, at what time, and whether it matched policy.
• Which providers are in the path, and what do they see? The fewer services involved in storing, authorizing, and logging a secret, the easier the system is to assess. Ours are listed, with what each one processes, in the sub-processor register.
• When you leave, what is actually erased, and when? A right to erasure that drags on for months, or that leaves your audit logs and backups behind, is not much of a right. Destroying your vault erases your secrets immediately and everything else within 30 days, backups included.

If you are working through these questions for build pipelines, our guide to CI/CD secrets management goes deeper. If you are surveying the field, we keep a broader overview of the best secrets management tools. And if the category is new to you, start with what a secrets manager is.

Why we built SikkerKey in Europe

We did not start with a region setting and a compliance page. We started from a position: the secrets layer is the most sensitive system a team runs, so it should be operated by a company you can locate, on infrastructure you can point to, under law you can name, with access enforced by cryptography you can inspect.

That makes SikkerKey a fit for teams that want a managed, GDPR-aligned secrets manager without becoming vault operators themselves, and especially for teams where the EU part is not optional:

• Your company or your customers are in the EU.
• You want your secrets, audit logs, and machine identities stored on EU infrastructure, under an EU company.
• You run CI/CD jobs, autoscaling fleets, or AI agents that need scoped, short-lived access.
• You need an audit trail that names real machines and answers incident questions fast.
• You want routine security checks like IP geolocation handled in-house, instead of sent out to third-party APIs.

EU hosting on its own does not make anything GDPR compliant, and we do not pretend otherwise. Compliance depends on the whole processing relationship: the agreements, the retention, the controls, and how you use the service. What an EU-stored, EU-governed, signed-request secrets manager gives you is a clean starting point, and an honest map of the few places traffic crosses a border on its way in.

That is what we are building. Start for free and move your first secret into a European secrets manager built for machines, CI pipelines, and AI agents. You can also see how SikkerKey is priced.

FAQ

Is SikkerKey a European secrets manager?

Yes. SikkerKey is operated by a Danish company, runs its vault on dedicated infrastructure in Germany, and stores your secrets, audit logs, and machine identities in the EU. Like any web service it sits behind a global edge for DNS, DDoS protection, and TLS, and it uses a payment processor for billing; both of those are US-based and listed in our sub-processor register. Neither is the system of record for your secrets, which are stored in the EU.

Is SikkerKey GDPR compliant because it runs on EU servers?

EU hosting is the easy part. GDPR is about the whole processing relationship, and we are built to it. SikkerKey is a Danish data controller; you can exercise your access, rectification, erasure, portability, restriction, and objection rights (Articles 15 to 21) at [email protected], with the Danish Data Protection Agency as your supervisory authority. Secrets are stored under three layers of AES-256-GCM with the decryption root held only in memory, so a database backup on its own cannot be read. We keep collection minimal (IP geolocation runs locally, and there is no third-party analytics, advertising, or profiling) and engage every sub-processor under an Article 28 agreement. And when you leave, you really leave: destroying your vault erases your secrets, audit logs, and machine identities from production and from our backups within 30 days. What EU hosting alone cannot do is make your organization GDPR compliant; that depends on how you use the service. Our privacy policy lists exactly what we collect, why, and for how long.

Is SikkerKey subject to the US CLOUD Act?

The CLOUD Act lets US authorities compel a company subject to US jurisdiction to produce data it holds. SikkerKey is a Danish company with no US parent or subsidiary, and your secrets, audit logs, and machine keys are stored in the EU, so there is no US company holding your vault that could be ordered to surrender it. We are straight about the rest: our edge provider and our payment processor are US-based and listed in our sub-processor register, and neither is where your secrets are stored.

Where are my secrets stored?

Encrypted, on dedicated servers in Germany, with the unlocking keys held apart from the stored data. Backups sit on a server we physically own and run in Denmark. All of it stays in the EU.

What happens to my data if I destroy my vault?

Destroying your vault is a deliberate, self-service action, gated behind your password, a typed confirmation, and a second factor or passkey. It immediately and permanently deletes your encrypted secrets and their full version history, along with your machines, projects, integrations, and sessions, straight from production, and it cannot be undone. Everything else tied to the vault, including the audit trail and your account record, is erased within 30 days, by which point the encrypted backups that held it have rolled off too. So your data is gone from both production and backups within 30 days. An account suspended for abuse may be kept longer on a legitimate-interest basis.

Does SikkerKey help with NIS2 and DORA?

It supports the parts a secrets layer is responsible for: per-secret access control, signed machine authentication, encrypted storage, a short named sub-processor list, and audit logs built for incident reporting. It does not, on its own, make your organization compliant, because both frameworks are organization-wide. Choosing an EU-established vendor also keeps a sensitive dependency out of third-country risk in your own assessment.

Are IP addresses personal data?

The European Commission treats an IP address as an example of personal data. That is why SikkerKey runs IP lookups locally, on its own servers, instead of sending each address to a third-party geolocation service during routine access checks.

How is SikkerKey different from a cloud-native secrets manager?

A cloud-native manager fits best when every workload already lives inside that one cloud's identity system. SikkerKey authenticates machines with signed requests, so a workload has a strong identity whether it runs in a cloud, on-premises, or in CI, and your secrets are stored with an EU company instead of inside a single non-EU provider.