Operate this solution

Use this guidance to prepare the validated private trust configuration for production and operate it across DigiCert® Account Manager, DigiCert® Private CA, DigiCert® Device Trust Manager, and DigiCert® Software Trust Manager. The implementation phases validate the DigiCert® ONE control plane and cryptographic outputs. Before production use, integrate those outputs with the actual device provisioning, relying services, trust distribution, and software release systems.

Production readiness checklist

• Both required workstreams are validated: device identity and code signing.
• Production identities are separated from the broad setup credentials.
• The approved root CA is distributed to the intended relying-party trust stores, and its fingerprint is verified through a separate trusted channel.
• Production device provisioning, key storage, and relying-service integration are defined and tested.
• Production signing-key storage, artifact tooling, approval controls, and verification are defined and tested.
• The non-secret resource list and secret-manager references are retained.
• The approved root fingerprint and trust-distribution owner are recorded.
• Credential and certificate renewal dates have assigned owners.
• Monitoring and audit ownership is established across every product boundary.
• Emergency revocation and escalation owners and procedures are documented.

Production identities

The cross-product service user in the setup phases simplifies implementation, but it is not the recommended identity for production operations. Follow the service-user and API-token best practices, and separate credentials by workload and environment:

This separation limits the impact of a compromised credential and makes revocation, ownership, and audit events attributable to one workload.

Monitoring

Monitor each product and the resulting certificates and keys:

Also monitor that relying parties still contain the approved root fingerprint. Successful issuance does not prove that deployed devices, services, or build verifiers trust the private root.

Credential rotation

Rotate an API token

You cannot recover or regenerate an existing API token secret. Follow the API token lifecycle procedure to create and deploy a replacement safely. To rotate the token, use the Account Manager API to create a new API token for an accessible service user. Send its user_id to POST /account/api/v1/api-access-token. Treat the response as a new credential with its own ID, lifetime, and returned-once secret.

Before you start, confirm that your tenant and administrator role permit an existing service user to have two overlapping API tokens. If they do not, create a replacement service user, deploy and verify both of its credentials, and then retire the old identity.

1. Authenticate as a standard or administrative user that can manage credentials for the service user’s account.

2. Create a new API token with an approved name and expiration:

   {
     "name": "Private trust runtime rotation",
     "end_date": "<approved-UTC-expiration>",
     "user_id": "<service-user-id>"
   }
   

3. Store the returned token directly in your approved secret manager.

4. Deploy the new token to one integration instance while retaining the old token for rollback.

5. Verify account access, device enrollment, and signing as applicable.

6. Shift all traffic to the new token.

7. Delete the old token with DELETE /account/api/v1/api-access-token/{id} according to your retention policy.

Rotate a client authentication certificate

Rotate the client authentication certificate separately from its associated API token. See Client certificate expiration and rotation for the complete certificate-management workflow.

1. Create a replacement certificate for the existing service user in Account Manager.
2. Deploy the new certificate and private key with the active API token.
3. Verify a protected signing operation.
4. Disable the old certificate with PUT /account/api/v1/client-auth-certificate/{certificate_id}/enable and {"enabled": false}.

Rotate a device enrollment passcode

Use usage limits and validity periods where operationally practical. Create a passcode credential shows how the solution creates a passcode on an authentication policy.

1. Create a replacement passcode on the existing authentication policy.
2. Update the enrollment clients to use the new passcode.
3. Verify enrollment with the new passcode.
4. Retire the old passcode.

Retry and rate-limit behavior

The current API references do not publish numeric rate limits. Follow the shared error-handling and rate-limit guidance. For 429 Too Many Requests and temporary 5xx responses, use exponential backoff with jitter and a maximum number of attempts. Honor Retry-After when present.

Do not automatically retry a POST request that creates or changes a resource unless you can prove the first request did not succeed or the API supports idempotency for that request. A lost response can otherwise create duplicate users, profiles, keypairs, certificates, or signatures. For setup automation:

• Use predictable, unique names and search before creating a resource.
• After a timeout with an uncertain result, retrieve the resource by exact name or request ID before retrying.
• Record non-secret resource IDs in durable state.
• Limit retries and send unresolved cases to an operator.

Approvals and polling

When a Device Trust Manager certificate policy requires approval, follow the guidance to handle an enrollment that requires approval. The initial enrollment response reports PENDING_APPROVAL and contains certificate_request_id. Poll:

GET /devicetrustmanager/certificate-issuance-service/api/v2/certificate-request/{certificate_request_id}/status

Use a polling interval between five and 10 seconds, and set a timeout. Treat APPROVED, AUTO_APPROVED, REJECTED, and CANCELED as final statuses. After approval, download the certificate using the approved-certificate endpoint instead of assuming the initial enrollment response contains certificate data.

Certificate and trust-anchor lifecycle

Use the CA certificates retained when you download and validate the CA certificates as the reference values for lifecycle monitoring.

• Renew or replace each issuing CA before its remaining validity becomes shorter than the maximum end-entity certificate validity.
• Publish and monitor the CRL, OCSP, Authority Information Access (AIA), and certificate distribution points required by the selected templates.
• Test root and intermediate rollover in a non-production trust store before deployment.
• Preserve the old root during an overlap period when issued certificates can still chain to it.
• Verify root fingerprints through a separate trusted channel before adding them to trust stores.
• Document emergency revocation procedures for the issuing CA, signing certificates, device certificates, API tokens, and client authentication certificates.

Scaling

• Use the Device Trust Manager batch device registration endpoint for controlled fleet provisioning rather than issuing one certificate per administrative call.
• Reuse profiles and policies where certificate purpose and controls are genuinely identical. Do not combine device and code-signing templates.
• Use the Software Trust Manager batch signing endpoint where it matches the artifact workflow, while retaining API token plus client-certificate authentication.
• Reuse TLS connections to reduce handshake overhead, but never share one signing credential across unrelated workloads or environments.
• Load-test against a demo tenant using representative payload sizes and approval behavior before production rollout.

Production signing

Sign and verify a known hash demonstrates key access and signature generation. A production release pipeline must additionally define:

• Supported artifact formats and signing tools (smctl, KSP, PKCS#11, or product-specific integration).
• Hardware security module (HSM) and key-access policy.
• Release windows and approval controls.
• Trusted timestamping where the artifact format supports it.
• Post-sign verification of the artifact, signing certificate, certificate path, and timestamp.
• Audit-log retention and correlation to the build, source revision, and approver.

Related pages

• Troubleshoot failed runs or requests with uncertain results.
• Look up implementation status, identifiers, and request formats.
• Return to the solution overview.