A node has no SSH server, login prompt, shell or user accounts. The kernel is built without loadable modules and boots with lockdown=confidentiality.

The management API is gRPC over TLS 1.3 with a client certificate required. A certificate that doesn't match the node's pinned admin is refused.

An unauthenticated UNIX socket serves the same API for on-box use only, with no network listener behind it. An unauthenticated reset works only there; over the network, reset needs the admin and the Root CA name typed back.

The node's etcd listens on 127.0.0.1 only and keeps its data on the encrypted state partition.

The node serves no web front end, compiled or otherwise. A web console exists only in FleetOS Manager, which runs off the node.

Why: Every web stack on the CA is more code that could be attacked. Nodes stay API-only by design.

Each Root is its own trust domain. CryptOS doesn't cross-sign one Root with another.

Why: Siloed Roots keep a compromise of one hierarchy from reaching another. It stays out until a real need appears.

In TPM mode the CA key is created inside the TPM under its storage root key, only its wrapped blob is stored, and export is refused.

The LUKS2 state partition's key is sealed in the TPM to PCR 7 (Secure Boot) and PCR 11 (the signed kernel image). A changed boot chain can't unseal it.

Before an upgrade or rollback, the node predicts the new PCR 11 and reseals the state key for exactly the images it can boot, adding before it removes.

CA keys in the TPM are ECDSA P-384 with SHA-384, or RSA of at least 3072 bits. Anything smaller is refused.

The nodeid (development) and kms modes keep the CA key in software on the encrypted partition, not in the TPM, and the code and docs say so plainly.

CA keys live only in the node's own TPM; a network HSM or PKCS#11 device for CA keys is out of scope. The kms mode wraps only the state disk's key with an external KMS. Saying so plainly in the docs is planned.

Open work: website#42 Say that CA keys stay in the TPM and a network HSM is out of scope

A Root key and its self-signed certificate are made in a first-boot ceremony, authorised by the admin certificate pinned in the machine config.

The ceremony writes an Ed25519-signed manifest, and tampering with it is detected. The signing key is derived on the node; it isn't an operator's signature.

Ceremonies are one person today. Requiring M of N key holders for Root operations isn't built.

Open work: cryptos-node#371 Build M-of-N quorum ceremonies

A reset needs the Root CA name typed back, compared in constant time, and fails closed. A quorum and one-time-code gate on top of it is planned.

Open work: cryptos-node#361 Require M-of-N quorum plus holder codes for a factory reset

The Root certificate the node self-signs is checked by zlint in the test suite with no errors and no warnings.

Every path to a certificate, the API and the ACME, EST and SCEP adapters included, goes through one profile engine that decides the extensions. A subordinate's path length is clamped to what its parent allows.

The raw SignCSR call is a stub in production builds; it exists only in a debug build tag.

SCEP enrolment, tested against the sscep client in CI.

ACME with http-01 and External Account Binding, and a strict JWS algorithm allow-list. dns-01, wildcards, key change and account deactivation aren't built.

Open work: cryptos-node#110 ACME HTTP-01/DNS-01 for cert-manager and native clients

An EST enrolment adapter over TLS.

The node publishes an RFC 5280 CRL and answers RFC 6960 OCSP requests when a revocation URL is set.

A built-in time-stamp authority that refuses SHA-1 and MD5 message imprints.

Config validation refuses ACME, EST, SCEP and the TSA on a Root, so a Root never answers enrolment requests.

Native Windows autoenrolment through Group Policy isn't built.

Open work: cryptos-node#108 Native Windows autoenrolment via GPO (MS-XCEP/WSTEP)

A node trusts exactly one admin certificate, pinned in its machine config. There are no roles or accounts on the node itself.

Operators sign in with a client certificate from your own operator CA. Viewer, operator and admin levels travel in the certificate. No passwords are stored.

Every request re-checks the operator's certificate against the manager's denylist, the CA's CRL and, where set, its OCSP responder.

Certificate requests wait for an operator or admin, the requester can't approve their own, and both identities are audited.

AI agents on the optional MCP endpoint get keys through an OAuth login that needs the operator's client certificate, and sensitive tools need a person's step-up approval.

Every node operation is appended to a SHA-256 hash chain, signed with a key kept apart from the CA key, on the encrypted partition.

cryptosctl lists the audit log and verifies its chain and signatures.

FleetOS Manager records every change with the acting operator, and the approval and approver where there is one, in a hash chain.

The node log grows without a retention policy today. Trimming it behind a signed checkpoint isn't built.

Open work: cryptos-node#327 Audit retention with a signed checkpoint

Each node keeps its own signed, hash-chained log, which cryptosctl reads and verifies on the node. Shipping it to a SIEM isn't built.

Open work: cryptos-node#408 Export the audit log to a SIEM

The signed kernel image carries the Go PID 1 and a SquashFS root that is mounted read-only. Only the encrypted state partition is writable.

Releases ship unsigned and the release pipeline checks they are. You sign the kernel image with your own Secure Boot key, so nothing in your chain of trust is signed by the project.

An upgrade image is checked against a detached signature before anything is written to the boot partition, and the previous image is kept for one rollback.

Measured boot gates the state disk (KEY-2). A node proves its identity by signing a challenge with its CA key; a TPM quote of its boot measurements isn't offered yet.

A time floor and NTP sync keep certificate validity and time-stamps from going backwards.

Node images are amd64 for VMware today. Proxmox VE, bare-metal installs and an arm64 image are in progress.

Open work: cryptos-appliance#38 Support Proxmox VE as a VM platform; cryptos-appliance#54 A plain installer ISO for bare-metal servers; cryptos-appliance#117 Build and prove an arm64 appliance image

Certificates are issued and revoked on the node that holds the CA. The manager carries CSRs and signed certificates; the only certificates it makes are its own first-run TLS certificate and each node's admin credential.

Adoption pauses until an admin confirms the node's certificate fingerprint against its console. A link request pins the node's CA key from a signed challenge and waits as pending until an admin approves it.

The node accepts only the admin credential the manager made for it, and the manager accepts only the node certificate it recorded. A node it can't verify is refused.

Marking an adopted node pending-link until its managed credentials are provisioned isn't built.

Open work: cryptos-manager#54 Mark adopted nodes pending-link until managed credentials are provisioned

The manager image is distroless, runs as a non-root user, and its base images are pinned by digest.

A software CA key can be exported and imported in a passphrase envelope (Argon2id and AES-256-GCM). A TPM key can't be exported, so it can't be escrowed.

Active and passive pairs with a shared address and lease-gated signing aren't built.

Recovering a Root through split custody (for example Shamir shares or smart cards) isn't built.

In TPM mode, if the PCR values drift outside an upgrade the state disk can't be unsealed and the node must be set up again. This is a stated limit, not a recovery path.

There is no backup of a node's etcd state today; only a software CA key can be escrowed (REC-1). An encrypted snapshot and restore isn't built.

Open work: cryptos-node#407 Encrypted backup and restore of a node's etcd state

The release pipeline builds the image twice and compares the outputs byte for byte. Releases carry SHA256SUMS and a build manifest.

The project doesn't sign the images you boot. You verify the checksums and sign with your own key (APP-2).

Why: A project key in your boot chain would make the project a party to your trust. You hold the keys, not us.

Release images carry no SBOM or provenance attestation; the image build sets them off.

Why: Reproducible builds and published checksums are the check today; an SBOM isn't scheduled.

Gitleaks runs in CI on every code repository.

Go code is formatted, linted, vetted and tested in CI, with a software TPM and interop tests, before it can merge.

Third-party GitHub Actions are pinned by commit SHA. A few org and tool references still float.

Key generation, signing and X.509 use only the Go standard library and golang.org/x/crypto. It is a written rule; no linter enforces it yet.

Vulnerabilities are reported privately through GitHub security advisories; the latest 0.x release gets fixes.

CI scans for secrets and runs the linters and tests, but no workflow checks for known vulnerabilities with govulncheck or runs gosec yet.

Open work: cryptos-node#406 Run govulncheck and gosec in the Go repos' CI