Operator identity
Every normal sign-in requires an individual . Privileged onboarding requires two independent approved authenticators, and shared privileged identities are prohibited.
Menu
Security / Public assurance position
Security claims should carry their boundaries with them.
This August 17, 2026 snapshot distinguishes implemented controls, retained evidence, deployment-acceptance requirements, continuing operational obligations, and residual risk.
Current determination
Strong implementation evidence. Production deployment is evidence-gated.
Major findings from the internal code and logic audit have been remediated in current source and backed by unit, adversarial, end-to-end, , , , , recovery, load, and controlled physical-appliance evidence.
A customer deployment is accepted only after its exact hardware, , and witnesses, recovery exercises, operating procedures, and independent review evidence have been evaluated. Source tests support that decision; they do not replace it.
Transport
Product control channels require TLS 1.3, , , no , and unique generated leaf identities for Rooks and authorized operator bridges.
Application encryption
Fresh , per-appliance secrets, , and protect sensitive control traffic. Citadel routes encrypted action and terminal data but does not receive the endpoint keys needed to read it.
Authority
, , , and signed, justified .
Endpoint
An unprivileged network transport separated from a , , , and signed start-time integrity verification.
Workspace
FIDO-backed access terminates inside a temporary constrained Forge environment with explicit destination, port, lifetime, bandwidth, connection, and restoration policy—not on the appliance host.
Portal boundary
Tenant-scoped roles, licensing, resource-aware attention workflows, encrypted sensitive scope metadata, durable rate limits, and signed evidence exports keep customer administration separate and attributable.
Recovery
, , signed , , and .
Evidence
, externally publishable , , , and protected failure records. External witnesses make or detectable.
Compromise model
Different failures cross different .
keeps Citadel outside operator action bodies, while and appliance boundaries contain the impact of an endpoint incident.
Citadel or its database
Availability, routing, fleet metadata, and daemon-side state are exposed. Operator payloads, terminal streams, and remain opaque without endpoint keys; the attacker still cannot forge an individual operator signature.
Portal host or database
account, tenant, approval, inventory, and workflow metadata must be treated as exposed during a live host compromise. Terminal, SSH, command, and plaintext are not handled by , and independently protected operator/Rook keys remain separate.
Operator workstation
That operator’s active session, local bridge, scoped certificate, and available signing capability are at risk. Password-plus- reauthentication, device revocation, short grants, and a genuinely separate approver limit but do not erase that impact.
Appliance root
The selected appliance must be treated as fully compromised. Root can request unsealing in an approved boot state and inspect live plaintext, while other appliances and offline signing roots remain separate.
Offline signing root
The affected signing purpose loses its trust guarantee. Purpose-separated roots limit , but recovery requires revocation, rollover, and a controlled fleet ceremony.
Qualification requirement
must anchor production trust.
An accepted baseline must bind the , firmware, BIOS configuration, and , Linux release, kernel, , and recovery policy.
That evidence must follow each appliance from enrollment through and ongoing fleet management.
Lifecycle assurance
Controlled change keeps the baseline intact.
Firmware, bootloader, kernel, policy, and agent changes move through measured approval, staged rollout, , recovery verification, and signed acceptance evidence.
Production acceptance
Outstanding requirements that must be evidenced.
- Place production release, policy, recovery, and acceptance-signing roots under
- Promote reviewed source through a governed release and coordinated fleet-upgrade ceremony
- Enroll and enforce per-appliance Attestation Keys, , and
- Qualify the selected production hardware and firmware combination at
- Retain signed audit witnesses in separately administered
- Integrate , , and enforceable
- Complete production-scale load, partition, failover, restore, and disaster-recovery exercises
- Complete independent cryptographic design, source-code, and penetration-test reviews
Scope of assurance
Confidence comes from a defined, verifiable boundary.
01
Assurance applies to the approved hardware, firmware, software, policy, key-custody, and operating profile
02
is established for the validated rather than inferred across a hardware family
03
Independent cryptographic, source-code, and penetration-test review complements continuous internal verification
04
Endpoint-root compromise remains a defined with contained fleet and offline-root
05
Regulatory, compliance, , and product certifications remain separate customer or market requirements
Disclosure boundary
Detailed enough to evaluate. Deliberately incomplete for operations.
Public material excludes credentials, private keys, exact operational endpoints, sensitive recovery contents, and exploitable deployment detail. Qualified reviewers can request a scoped briefing and the controlled protocol, threat-model, and assurance record.
Prepare a briefing request