dorfteich/docs/architecture/adr/0019-no-security-base-functions.md

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).