ProductionChecklist.md

Production readiness checklist

The samples and Getting started use shortcuts that are suitable only on a development computer: temporary certificate stores, automatic certificate acceptance, anonymous users, and short reconnect limits. Review this checklist before you deploy a client or server. Each item links to the guide that explains the setting. The checklist does not replace a security review of your deployment.

Contents

• Production readiness checklist
  • Application identity and certificates
  • Endpoints and message security
  • Users and permissions
  • Secrets and private keys
  • Resource limits
  • Diagnostics and auditing
  • Clients
  • Deployment and operation

Application identity and certificates

• Give each installation a unique ApplicationUri that matches its application certificate. See Concepts: applications.
• Ensure PkiRoot points to persistent, access-controlled storage. When no root is configured, hosted clients and servers use the running account's LocalApplicationData/OPC Foundation/{ApplicationName}/pki; samples may override this location. See Application identity and certificate defaults.
• Keep AutoAcceptUntrustedCertificates disabled, and provision the trusted and issuer certificates, or CA-issued certificates, before peers connect. See Certificates.
• Keep SHA-1 certificates rejected and an RSA key size of at least 2048 bits; both are the defaults. See Server security and resource controls.
• Plan certificate renewal and trust-list updates, for example with certificate-expiration alarms, push management, or a Global Discovery Server. See Certificate manager and GDS.

Endpoints and message security

• Offer SignAndEncrypt endpoints and keep IncludeUnsecurePolicyNone set to false; both are the hosted-server defaults. See Server security and resource controls.
• Enable IncludeEccPolicies only when every client supports the ECC policies. On .NET Framework the ECDH agreement and the AES-GCM and ChaCha20-Poly1305 ciphers run in BouncyCastle rather than a validated module. See ECC profiles: known limitations.
• Configure clients to select a SignAndEncrypt endpoint. See Concepts: endpoints, secure channels, and sessions.

Users and permissions

• Decide whether anonymous access is acceptable. A hosted server without UserTokenPolicies advertises an Anonymous policy. See User token policies.
• Register an authenticator for each user-token policy that the server advertises, for example with AddDefaultIdentityAuthenticators. A policy without an authenticator does not authenticate users. See Identity providers.
• Map identities to roles and restrict node permissions. See Role-based user management.
• Set session and channel ceilings for the expected load, and keep the failed-authentication lockout (MaxFailedAuthenticationAttempts, default 5). See Server security and resource controls.

Secrets and private keys

• Keep passwords, tokens, and private keys out of source code, configuration files in source control, and container images.
• Store credentials through an ISecretStore that is backed by a durable, access-controlled secret service; a hosted server registers one with AddSecretStore. See Dependency injection: server feature.
• Where policy requires it, keep private keys in a TPM, HSM, PKCS#11 token, or key service. See Crypto providers.

Resource limits

• Review the transport quotas (MaxMessageSize, MaxArrayLength, MaxByteStringLength) and the service OperationLimits. See Operation limits.
• Tune the admission rate limits, which are enabled by default, with ConfigureRateLimits. See Rate limiting.
• Review the resource-isolation profile; Balanced is the default. See Server resource isolation.
• Size the server for the expected sessions, subscriptions, and monitored items. See Server scalability.
• Enable Server GC for servers under load, and size the request queue for the pipelining of your clients. See Runtime and host settings.

Diagnostics and auditing

• Send logs, metrics, and traces to your monitoring system through the host's logging and ITelemetryContext. See Diagnostics.
• Enable audit events when you must record security-relevant actions; they are off by default. See Enabling auditing.
• Decide whether to keep the server diagnostics nodes (DiagnosticsEnabled, default true), which add per-session and per-subscription work. See Enabling diagnostics.
• Use packet capture and key logs only for troubleshooting. Key logs make captured traffic decryptable. See Diagnostics: security model.

Clients

• Keep the default reconnect policy for long-running clients. The Getting started client limits retries only to report errors quickly. See Reconnect semantics.
• Trust server certificates explicitly instead of accepting them automatically. See Certificates.
• Store namespace URIs, not namespace indexes, and resolve indexes after each connection. See Concepts: node identity and namespaces.
• Pass cancellation tokens and dispose sessions and subscriptions. See Concepts: how the SDK is organized.
• For clients that receive more than about a million notifications per second, enable Server GC (<ServerGarbageCollection>true</ServerGarbageCollection>) or a larger gen0 budget (DOTNET_GCgen0size). With Workstation GC the notifications in flight outgrow gen0, every collection promotes them, and the client falls behind the server. Keep deferred notification decoding on (the default), and give classic subscriptions a small MaxMessageCount, such as 1. See Deferred notification decoding.

Deployment and operation

• Keep the clocks of clients and servers synchronized, for example with NTP or PTP. Certificate validity, timestamps, and redundancy depend on it. See Kubernetes: time synchronization.
• In containers, mount the certificate stores on persistent storage and supply secrets at run time. See Container reference server and Kubernetes: secrets, certificates, and trust.
• Use a Global Discovery Server or provisioning mode to manage certificates across many installations. See GDS and Provisioning mode.
• Add redundancy only when availability requirements need it. See High availability.