# Security

> InfraNest holds the keys to your infrastructure. Here is exactly how they are stored, who can reach them, where they live, and what we do not claim.

Source: https://infranest.io/security

---

To manage your domains, DNS, servers and certificates in one place, InfraNest holds something
genuinely sensitive: the API credentials to your registrars, DNS hosts and cloud providers. We think
you should know exactly what happens to them before you hand them over — not after.

This page is specific on purpose. Where we have something real, we describe how it works. Where we
don't, we say so.

## The short version

- Every organisation's credentials are encrypted under **its own key**. A breach of one customer's
  key does not open anyone else's.
- Delete your account and, once the deletion becomes final at the end of the recycle-bin period, we
  **destroy that key** — which makes your secrets unreadable everywhere, including in backups.
- We **never store a private key we did not generate.**
- Sign in with a **passkey** — and removing one always makes you prove it's still you.
- **Every change is recorded** in an audit log you can read yourself.
- Your data lives in **Germany**, in ISO 27001-certified data centres, with off-site backups
  inside the EU.
- We are **not** ISO 27001 or SOC 2 certified. [Here's what we do instead](#what-we-don-t-claim).

## Your provider credentials

When you connect a registrar, DNS host or cloud account, the credentials are encrypted the moment
they arrive and are never shown again.

**Each organisation gets its own encryption key.** Your secrets are encrypted with a key that belongs
to your organisation alone, which is itself protected by our master key. This is the part worth
understanding: it means the blast radius of a compromised key is **one customer**, not all of them.
Most platforms encrypt everything under a single key and describe it the same way.

**Deleting your account destroys that key — when the deletion becomes final.** A deleted account first
sits in a recycle bin for a grace period, so an accidental deletion can be undone; once that window
closes and the deletion is final, the key is destroyed. After that your secrets can't be read again —
not by us, and not from a backup or replica taken while your account existed. Deletion actually reaches
the copies nobody can go back and edit.

**Secrets are shown once.** API tokens, webhook signing secrets and two-factor recovery codes are
displayed when they're created and never returned again — not in the interface, not through the API.

**Secrets are stripped from our diagnostic logs.** When InfraNest calls a provider on your behalf, we
record the request so a failure can be traced. Anything that looks like a secret is replaced before
the record is written — including the server start-up scripts that often carry database passwords and
registry credentials. The redaction happens centrally, so it can't be forgotten in one place.

**Your provider accounts stay yours.** Registrars, DNS hosts, cloud providers and chat channels you
connect with your own credentials remain under your agreement with them. You can revoke our access at
any time, from their side or ours.

## TLS private keys

Our rule, in full:

> We never store a private key we did not generate. We store keys we issued, encrypted, because
> nobody else has them.

Your certificate inventory holds metadata only — fingerprint, subject, issuer, names, validity. There
is no private-key column. When a certificate was issued and is renewed by a provider, we fetch the
deployable bundle from them at the moment you ask for it, hand it to you, and keep nothing.

Not storing it is both safer and more correct: those certificates rotate every 60–90 days, so a stored
key would be stale within the quarter — and a stale private key is worse than none, because it
installs cleanly and then breaks TLS for a reason nobody traces back to us.

Certificates **we** issue are the other half of the rule. We generate the key, the certificate
authority doesn't keep it, and without ours the certificate can't be delivered or renewed — so we do
store it, encrypted under your organisation's key like every other secret above.

## Your account

- **Passkeys.** Sign in with Face ID, Touch ID or a hardware key — no password to phish. You can use a
  passkey on its own, or as a second factor after a password.
- **Step-up confirmation.** Removing a passkey always re-authenticates you first — you prove it's still
  you. Your organisation can extend that same step-up to destructive and power actions from its Security
  settings (it's off until an admin turns it on).
- **Two-factor authentication (TOTP)** with any authenticator app. Your recovery codes are hashed, so
  even we can't read them, and shown to you only once.
- **Dropping your password entirely** is allowed only once you have a phishing-resistant fallback — a
  second passkey, or confirmed 2FA with its recovery codes. We won't let you leave a password as the
  weak way back in, because that would reopen the hole passkeys exist to close.
- **Account lockout** after repeated failed sign-ins, recorded as a security event you can see.
- **Bot protection** on sign-up and password reset, and adaptively on sign-in after repeated failures.
- **Sessions you can see and revoke.** Every active session lists its IP, device and approximate
  location, so an unfamiliar one is obvious. Idle sessions expire on their own, and signing in again
  from the same browser replaces the old session rather than stacking up another.
- **Scoped API tokens.** Mint a token that only reads, or that reaches only part of InfraNest. The
  picker names what each scope actually covers, because the scopes are deliberately coarser than their
  labels suggest. Two things a scope does not restrict today: global search, and creating another
  token — so treat any token you issue as able to mint a full-access one, and revoke what you stop
  using.

## Who can see your data

**Every request is scoped to your organisation**, and both layers of our permission system deny by
default: if a permission isn't explicitly granted, the answer is no. Organisations can define their own
roles from the same permission set.

**Our support access is read-only.** When a member of our team needs to look at an account to help
with a problem, writes are blocked across the entire API for the duration. Support can look. Support
cannot touch.

## Every change is recorded

Every action that creates, changes or deletes something is written to an audit log you can read
yourself, in your organisation's settings — who did it, what changed, and when. Actions taken
automatically on your behalf are recorded too, marked as system actions.

This isn't a promise we keep by remembering. Our build pipeline walks every endpoint that changes data
and **fails the release** if one doesn't record to the audit log. Coverage is checked by machine, on
every change we ship.

**How long we keep it depends on your plan** — from 7 days on the entry plan up to 10 years at the
top. The figure for each plan is on our [pricing page](/pricing), which is the one that stays current.
You can export the log at any time, so if you need to keep a longer record than your plan retains, take
it before it ages out.

## Where your data lives

**Your account, your data and your credentials are hosted in Germany**, in Nuremberg, on Hetzner
infrastructure certified to ISO/IEC 27001:2022 and BSI C5 Type 2. Our database runs on its own server,
separate from the application.

That isn't only where the machines happen to be. We hold a signed **Article 28 data-processing
agreement** with Hetzner that confines processing to the EU and the EEA, and because we host in
Germany, none of the sub-processors they operate outside the EU touch your data at all. Their
data centres separate one customer's data — and one customer's backups — from another's at the
virtualisation layer.

What Hetzner does **not** do is encrypt your data for us. Their agreement says so plainly: encryption
at rest, of both the data and the backups, is the customer's job. That customer is us, and the rest of
this page is how we do it. It is worth knowing that a hosting certificate never covers this part —
ours or anyone's.

**Monitoring probes are different, and you choose them.** Checks run from probe servers in the regions
*you* select — currently Europe, Asia and North America, with more added over time. A probe holds no
credentials to your account and no keys to anything you've connected: it runs a fixed, versioned image,
authenticates outbound to us with its own scoped token, and reports a result.

What a probe does receive is the definition of the checks it runs — the address to check and any
settings you configured for it, **including custom request headers**. If you set an authorisation
header on a check, it is sent to the probes in the regions you picked. If you'd rather that never left
the EU, select EU regions only.

**Backups leave Germany, but not the EU.** The database is backed up daily to Backblaze B2 in their
EU (Amsterdam) region, and we snapshot the production database before every migration. Your provider
credentials stay encrypted under your organisation's key *inside* those backups — a backup is not a
way around anything described above.

## Infrastructure and transport

- **Everything travels over TLS.** HTTPS is enforced with HSTS, so browsers won't fall back.
- **Hardened browser headers** on both the app and the API — clickjacking, MIME-sniffing and referrer
  leakage are all closed off, and camera, microphone, geolocation and USB access are disabled outright.
- **Hardened hosts** — automatic security updates, restricted SSH, firewalling and pinned dependencies.
- **Guarded releases.** Production only updates through a reviewed, CI-tested pull request. We take a
  database snapshot before every migration and verify our encryption key is present before deploying.
- **We block our own servers from being used against you.** Any address you give us that we then fetch
  — a monitor target, a webhook — is checked to make sure it isn't pointing back at internal or cloud
  metadata addresses.

## Our providers, and what they are certified for

We keep this list short on purpose. These are certifications held by **our providers**, covering their
own infrastructure and services — not certifications of InfraNest.

| Provider | What they do for us | Where | Their certifications |
|---|---|---|---|
| **Hetzner** | Application, database and back-office hosting | Germany (EU) | ISO/IEC 27001:2022; BSI C5 Type 2 |
| **Cloudflare** | Marketing site delivery, CDN and bot protection; transactional email | EU / global | Published on their trust page |
| **OVHcloud** | Monitoring probe servers | Worldwide, region of your choice | Published on their compliance page |
| **Stripe** | Payment processing — we never see your card number | EU / US | PCI DSS Level 1 |
| **Sentry** | Error diagnostics — pseudonymous account id only | EU / US | Published on their trust page |
| **Backblaze B2** | Off-site database backups | EU (Amsterdam); US company | Published on their trust page |

Hosting runs under a signed **Article 28 data-processing agreement** with Hetzner, with processing
contractually confined to the EU/EEA. Every provider above is bound by data-protection terms meeting
Article 28, and we stay responsible to you for what they do.

Analytics is **Umami, self-hosted on our own infrastructure** and cookieless — no third-party analytics
company receives your data.

Two more receive data only if you switch them on: **Telegram**, if you set up a Telegram alert channel
(we operate the bot, and Telegram is outside the EU), and **Gravatar**, if you enable avatar images —
which we fetch server-side from a hash of your email, so Gravatar never sees your browser or IP.

The complete list, including what each one processes, is in our
[Data Processing Agreement](/dpa) and [Privacy Policy](/privacy). We give **30 days' notice** before
adding or replacing a sub-processor.

## What we don't claim

**InfraNest is not ISO 27001 or SOC 2 certified.** We're a small, independent company, and those
audits are a significant undertaking we haven't yet completed. We'd rather tell you that plainly than
put a certification badge on this page that belongs to our landlord.

What we do instead is on the rest of this page: encryption designed so one breach is one customer,
deletion that reaches backups, private keys we refuse to hold, and audit coverage a machine checks on
every release. We'd encourage you to weigh that against a certificate — and to ask us hard questions
either way.

If your procurement process needs a security questionnaire completed, send it to us. We answer them.

## Reporting a vulnerability

If you've found a security issue, please email **security@infranest.io** rather than opening a public
issue. That address is also published at
[/.well-known/security.txt](https://infranest.io/.well-known/security.txt).

We commit to:

- an acknowledgement within **3 business days**
- a triage assessment and severity rating within **7 business days**
- regular updates while we fix it, and credit in the release notes if you'd like it

Please include steps to reproduce, and avoid accessing other customers' data while investigating.

## Also worth reading

[Privacy Policy](/privacy) · [Data Processing Agreement](/dpa) · [Terms](/terms) ·
[Imprint](/impressum) · [Service status](https://status.infranest.io)

Questions about anything here: **security@infranest.io**

_Last reviewed: 30 August 2026._