For compliance officers

Regulatory alignment

Confium ships hooks for FIPS 140 mode, jurisdictional algorithm allow-lists, and structured audit logging. This page maps those features to eIDAS, HIPAA, FedRAMP, and other common frameworks.

FIPS 140 mode

FIPS mode routes every cryptographic operation through a FIPS-validated plugin (typically Botan in FIPS mode). The engine refuses to use non-FIPS-validated primitives even if they\'re installed. 

Confium::Policy.fips_mode = true

In FIPS mode:

  • SHA-1, RSA-1024, and other legacy algorithms are rejected even if allow-listed.
  • The Botan plugin (when built against a FIPS-validated Botan) is the preferred backend.
  • Random number generation uses the FIPS-approved DRBG.
  • Self-tests run at startup and periodically per FIPS 140-2 §4.9.

Jurisdictional algorithm policies

Beyond FIPS, individual jurisdictions have specific algorithm requirements. Confium expresses these as allow-lists:

European Union (P-384+)

Confium::Policy.configure do |p|
  p.allowed_signature_algorithms = %w[ECDSA-P384 ECDSA-P521]
  p.allowed_hash_algorithms = %w[SHA-384 SHA-512]
end

United States (P-256 acceptable)

Confium::Policy.configure do |p|
  p.allowed_signature_algorithms = %w[ECDSA-P256 ECDSA-P384 Ed25519]
  p.allowed_hash_algorithms = %w[SHA-256 SHA-384 SHA-512]
end

China (SM2 / SM3)

Confium::Policy.configure do |p|
  p.allowed_signature_algorithms = %w[SM2]
  p.allowed_hash_algorithms = %w[SM3]
end

SM2/SM3 support requires the SM plugin bundle; the engine rejects these algorithms if the plugin is not loaded.

Post-quantum-required (forward-looking)

Confium::Policy.configure do |p|
  p.require_pq_component = true
  p.allowed_signature_algorithms = %w[
    ECDSA-P256
    Ed25519
    ML-DSA-65
  ]
end

With require_pq_component = true, the engine only accepts composite signatures that include at least one post-quantum algorithm. Useful for long-lived signatures (code signing, archival) where migration to PQ is a regulatory or business requirement.

Audit log format

Every signing operation produces a structured audit record. The format is JSON, suitable for ingestion into SIEM systems (Splunk, Elastic, Datadog, etc.). 

{
  "event_id": "evt_01H8X9...",
  "timestamp": "2026-07-28T14:23:42.118Z",
  "session_id": "sess_8a92...",
  "coordinator": "coord-eu.internal",
  "operation": "sign",
  "algorithm": "ECDSA-P256",
  "message_hash": "sha256:9b1d...",
  "signature_hash": "sha256:7c3e...",
  "transparency_sequence": 18437,
  "quorum": {
    "required": 3,
    "participating": 3,
    "signers": ["director-1", "director-3", "director-5"]
  },
  "attributes": {
    "region": ["na", "eu", "apac"]
  },
  "policy_version": "deploy.toml@abc123",
  "fips_mode": true
}

The transparency log anchors each audit record\'s event_id as a Merkle leaf. The inclusion proof cryptographically binds the audit record to a public, verifiable timeline.

Regulatory framework mapping

FrameworkRelevant Confium features
eIDAS (EU, electronic signatures)
  • Jurisdictional policy enforcing P-384+ for Qualified Electronic Signatures.
  • Audit log with signer identity + attributes.
  • Transparency log for long-term verifiability (eIDAS Article 50).
HIPAA (US, healthcare)
  • Audit trail of every signing operation (§164.312(b)).
  • FIPS 140 mode for cryptographic primitives (§164.312(a)(2)(iv)).
  • Threshold key escrow pattern for break-glass access.
FedRAMP (US, federal cloud)
  • FIPS 140-2 validated cryptography.
  • Structured audit log ingestible into SIEM.
  • Attribute-based access control for signer authorization.
Common Criteria (EAL4+)
  • Open-source codebase for full audit.
  • #![forbid(unsafe_code)] for memory safety.
  • Type-safe errors (no string-error attack surface).
GDPR (data minimization)
  • Audit log records hashes, not message contents.
  • No personal data in transparency log entries (only event hashes).
SOC 2 Type II
  • Transparency log provides immutable audit trail.
  • Attribute-based quorum for separation of duties.
  • Structured audit log for monitoring controls.

This table is informational, not a certification. Each deployment must complete its own compliance assessment.

Deployment manifest as policy artifact

The TOML deployment manifest is the canonical policy artifact. Treat it like any other audited configuration:

  • Version it in git.
  • Require code review for changes.
  • Sign it (Confium can verify its own manifest signature at boot).
  • Audit changes against the change-management control of your compliance framework.
[policy]
fips_mode = true
allowed_signature_algorithms = ["ECDSA-P384", "Ed25519"]
allowed_hash_algorithms = ["SHA-384", "SHA-512"]
require_pq_component = false

[quorum]
threshold = 3
total = 5
diversity = { regions = 3 }

Where to go next