OpSec Security

Operational security protects the people, credentials, systems, and recovery processes around a Canton application. A strong Daml model cannot help if an administrator, CI pipeline, or participant identity is compromised.

• Inventory signing keys, participant identities, OIDC secrets, cloud credentials, CI tokens, database passwords, and recovery material.
• Record an owner and purpose for every secret.
• Keep production, test, development, and personal credentials separate.
• Use managed KMS or HSM-backed storage where supported.
• Require hardware-backed MFA for source control, cloud, CI, identity systems, password managers, and production access.
• Use separate daily and administrator accounts.
• Give production access for a limited time.
• Avoid shared administrator accounts.
• Define rotation, revocation, and recovery procedures.
• Encrypt backups and store recovery copies away from the main environment.

Start with the official Cryptographic keys in Canton guide and its explanation of storage options. The local and external parties reference describes the trust placed in submitting participant nodes and external signers.

• Use managed devices for privileged work.
• Enable full-disk encryption and automatic updates.
• Minimize browser extensions and local production secrets.
• Verify domains before entering credentials.
• Reject unexpected MFA prompts.
• Confirm urgent access, invoice, key, and support requests through a second channel.
• Do not paste secrets, customer data, private code, or findings into unapproved AI tools.
• Treat AI-generated shell commands, infrastructure code, and recovery steps as untrusted until reviewed.
• Train staff to report mistakes quickly without hiding them.
• Remove access immediately when a person changes role or leaves.

Our Web3 OpSec incident review shows that phishing, fake tools, stolen sessions, and poor secret handling cause serious losses. Our AI and Formal Verification article also explains why automation must remain under human control.

• Protect the main branch.
• Require pull-request and code-owner review.
• Require tests and security checks before merging.
• Review AI-generated code as carefully as external code.
• Restrict who can change CI workflows, publish packages, push images, and deploy production.
• Use short-lived workload identity instead of static cloud keys where possible.
• Separate build, deployment, and runtime credentials.
• Pin third-party actions and dependencies.
• Scan source, secrets, dependencies, containers, and infrastructure code.
• Deploy immutable versions.
• Record who approved and started each production deployment.
• Keep a tested rollback and Daml package-upgrade process.

The SCAS article Maximizing the Value of Your Smart Contract Audit explains why clean scope, clear documentation, and meaningful tests matter before an audit. Those same practices reduce release risk.

• Follow the current Digital Asset guidance for the exact Canton release.
• Keep participant and validator admin APIs private.
• Restrict inbound and outbound network access.
• Use TLS and strong OIDC settings.
• Use different token audiences for different deployments.
• Do not share identities, databases, volumes, or credentials across development, test, and production.
• Back up participant identities, databases, configuration, and identity provider settings.
• Define acceptable data loss and downtime.
• Test a full restore in an isolated environment.
• Monitor service health, database health, resource use, ledger lag, login failures, and admin changes.
• Patch through a staging process.
• Keep a clear inventory of versions, endpoints, owners, and dependencies.

The SCAS Canton Validator Guide covers deployment, identity, backups, monitoring, and common setup failures. The Canton audit service also reviews participant-node and infrastructure security.

• Centralize logs outside the system being monitored.
• Alert on new administrators, MFA resets, permission changes, CI changes, package uploads, backup failures, and disabled security controls.
• Pre-assign who may revoke users, rotate keys, stop deployments, isolate services, and contact Canton counterparties.
• Preserve logs and release evidence before rebuilding, then rotate all related credentials rather than only the first exposed secret.
• Rotate related credentials, not only the first leaked secret.
• Review recent releases, packages, and ledger activity.
• Protect the domain registrar, DNS, certificates, support email, and public security contact.

Use NIST SP 800-61 Rev. 3 as the incident-response framework for preparation, detection, response, and recovery.