> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockops.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Security checklist

> The controls a self-hosted citadel-core deployment must have in place before it holds production key shares.

Use this list before the cluster generates its first production key, and again at each review. Every item is something the platform expects your operators to own in the hybrid and self-hosted models; none of it is enforced by Blockops on your behalf.

## Key material

* [ ] Peer registry, identities, initiator key, authorizer keys, passwords and the chain code were generated on a secure, ephemeral workstation that was wiped afterwards.
* [ ] Node private keys are encrypted at rest (`generate-identity --encrypt`) and decrypted only in memory at start-up.
* [ ] The initiator's private key lives only with citadel-api; no node has a copy.
* [ ] Share-store passwords and identity passwords are in a secrets manager, never in `config.yaml`, task definitions, environment variables, images or version control.
* [ ] The chain code is stored with the same care as a password and is identical on every node.
* [ ] Backups of the share store, identity files and passwords exist, are tested by an actual restore, and are stored separately from the nodes.

## Hosts and containers

* [ ] Nodes run as an unprivileged user (`citadel-core` on hosts, UID `65532` in containers) with a read-only root filesystem and all capabilities dropped.
* [ ] The configuration directory is root-owned and read-only to the service; only the data directory is writable.
* [ ] On hosts, the systemd unit keeps `NoNewPrivileges`, `ProtectSystem`, `ProtectHome`, `PrivateTmp` and the system-call filter from the unit Blockops provides.
* [ ] Nodes run on infrastructure with no public IP address, in private subnets or an isolated namespace.
* [ ] Storage holding the share store is encrypted at rest at the platform level as well (EFS encryption, encrypted persistent volumes, disk encryption on hosts).

## Network

* [ ] Egress from nodes is limited to NATS, Consul, and (on ECS) S3, Secrets Manager and ECR through VPC endpoints.
* [ ] Ingress to nodes is limited to the other nodes (and the health port from the orchestrator).
* [ ] NATS uses TLS with client certificates and credentials; `environment: production` is set so the node refuses to connect otherwise.
* [ ] Consul ACLs are enabled and the nodes' token can read and write only the peer registry.

## Operations

* [ ] Exactly one instance of each node runs at a time (`desired_count = 1` on ECS; a StatefulSet on Kubernetes).
* [ ] Logs are retained centrally with a retention period set, and the `--debug` flag is off.
* [ ] Health checks are wired to readiness, not liveness.
* [ ] Upgrades are applied one node at a time and never take the cluster below threshold.
* [ ] Access to hosts, the cluster and the cloud account is restricted, logged and reviewed: an operator who can read a node's memory and its password can extract a share.
* [ ] The resharing and node-replacement procedures in [Operate a cluster](/self-hosted/operate) have been rehearsed.

## What this does not cover

Policy, approvals, limits and the withdrawal freeze are enforced by citadel-api, not by the nodes; see [Policies & approvals](/wallets/policies-and-approvals). A compromised node cannot sign alone, but a compromised initiator key combined with a threshold of compromised nodes can; protect both.