# ADR 0019: No security base functions in the application (§52 VSA)

- Status: proposed
- Date: 2026-07-29

## Context

Dorfteich is to be operable inside an IT environment of a German federal
authority that is approved under the Verschlusssachenanweisung (VSA), for
content classified VS-NfD. **No BSI certification of Dorfteich itself is
sought.**

§51 VSA makes products that provide a _Sicherheitsgrundfunktion_ subject to
certification. §52 VSA enumerates those base functions: encryption, media
protection (Datenträgerschutz), network termination (Netzabschluss), and
authentication. A product that implements one of them itself moves into the
certification obligation — an outcome that would end this undertaking on
cost grounds alone.

Today Dorfteich sits close to the right side of that line, partly by
accident and partly by design: there is no content encryption, no backup
encryption, no own MFA, and no cryptographic primitive of our own beyond
signing short-lived collaboration tokens and hashing credentials. What is
missing is the _decision_ — so that no future feature crosses the line
because nobody had written down where it runs.

## Decision

**Dorfteich does not provide any security base function within the meaning
of §52 VSA. Encryption, media protection, network termination and
authentication belong to the operator's platform.**

Concretely:

1. **No encryption of content**, neither in the database nor on the file
   system. Confidentiality of stored data is provided by the platform
   (full-disk / volume encryption).
2. **No backup encryption in the application.** Media protection is the
   platform's function; the application restricts _where_ backups may go
   (ADR 0026) and nothing more.
3. **No own MFA, no own password policy engine.** Authentication is
   delegated to the operator's identity provider (ADR 0021). Local
   passwords remain available for non-VS deployments and are hard-switchable
   off.
4. **No new cryptographic primitives.** Existing crypto is limited to
   credential hashing (Argon2id), token hashing (SHA-256) and signing
   short-lived tokens, and it uses vetted libraries rather than
   hand-written constructions (ADR 0020).
5. **No TLS termination, no network segmentation** in the application.
6. **No application-side separation of classification levels.** Levels are
   separated by operating one instance per level; the application only
   _marks_ content (ADR 0022).

The application's contribution to security is a different set of
properties, and these it does own: a central, default-closed permission
model; complete absence of outbound connections; verifiable marking of
classified content in every output channel; and an audit trail.

## Consequences

- Deliberate non-features must be argued as architecture, not apologised
  for as gaps. "No encryption in the code" is the correct division of
  labour under §52 VSA.
- Every feature proposal is measured against this ADR. Any change that
  would make the application the bearer of a base function needs to amend
  this ADR first — which is the point of writing it down.
- The operator carries obligations that must be handed over explicitly and
  in writing. This ADR is therefore the **draft of the delimitation
  statement** (Abgrenzungserklärung) that #226 turns into a
  reviewer-facing document; the two must not diverge.
- Anything the platform cannot supply because it lacks application
  knowledge stays with us. Two cases exist today: marking of classified
  content (only the application knows the classification, ADR 0022) and
  integrity of the application's own payloads (#199).
- Residual risks arising from delegation are listed in #231 rather than
  silently accepted.

## Implementing issues

#226 (delimitation statement), #227 (hardening guide), #228 (security
documentation), #229 (operations manual), #230 (IT-Grundschutz mapping),
#231 (residual-risk list).