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 your 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.
• The operational certificate policy is defined, or bootstrap-only issuance is an accepted decision.
• 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.

Clean up a validation run

A validation run leaves resources in the tenant: a division, certificate profile, certificate policy, authentication policy, passcode, device group, device record and certificate, keypair, signing certificate, service user, API token, and client authentication certificate. In a shared demo tenant, these resources can interfere with later runs because the manual selects resources by exact name.

Remove these resources only after recording the evidence you need. Work from the saved values, confirm every ID and exact name, and use identities authorized for cleanup. The setup role does not grant every Software Trust cleanup operation. Certificate revocation requires REVOKE_SM_CERTIFICATE. Depending on the team configuration, keypair deletion can require APPROVE_SM_KEYPAIR_DELETE, MANAGE_SM_KEYPAIR, or an approval control. Do not broaden the setup identity only to simplify cleanup.

Use this dependency order:

1. Copy the verified root fingerprint, certificate-path validation output, and signature-verification result to the approved evidence store. Confirm that none of the target resources carries production traffic.
2. If your validation plan requires revocation evidence and the cleanup identity is authorized, revoke the device certificate and private code-signing certificate.
3. Disable or delete the validation device record identified by device_id.
4. Disable and delete the device group. Remove the group before the authentication policy and certificate policy it references.
5. Delete the passcode, then delete the authentication policy.
6. Remove the Device Trust Manager certificate policy through the documented product workflow. The API exposes the policy status but does not provide a matching delete operation. After the policy is no longer in use, delete the device certificate profile and then the division with their documented API operations.
7. Delete the software-backed test keypair with DELETE /signingmanager/api/v1/keypairs/{keypair_id}?account_id={account_id} over the clientauth. host, or take it offline where retention policy requires the key history. This delete operation accepts only software-backed (DISK) keypairs.
8. Disable the Software Trust Manager private trust certificate profile with PUT /signingmanager/api/v1/certificate-profiles/{signing_profile_id}/disable. The API does not provide a certificate-profile delete operation.
9. Authenticate as the bootstrap administrator that can manage the service user. Disable the client authentication certificate with PUT /account/api/v1/client-auth-certificate/{client_auth_certificate_id}/enable and {"enabled": false}, delete the API token with DELETE /account/api/v1/api-access-token/{api_token_id}, then disable or delete the service user. Finish every request that needs the setup credential before deleting it.
10. Securely remove the generated files listed in Files each phase writes and their secret-manager entries according to your retention policy. Remove the dedicated validation directory only after confirming that it contains no unrelated files and that retained evidence is stored elsewhere.

Keep the run’s evidence even after deleting the resources. Those results are not reproducible from a deleted resource.

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 confirm that relying parties retain 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 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.

Apply this rule even when the service returns a definite non-2xx status. A Software Trust Manager keypair creation request can return 404 for a license error after committing the unique keypair. Search by the retained exact alias and retrieve the matching record before deciding whether another create request is safe.

Device registration recovery

This solution configures require_approval_for_enroll: false and registers the managed device through POST /devicetrustmanager/api/v4/device/registration. The successful response contains the bootstrap certificate and server-generated private key; it does not use certificate-request approval polling.

If a registration result is uncertain, search the device inventory by its exact unique name before another state-changing request. If the device exists, do not register a duplicate. Recover the certificate and request IDs through certificate inventory using the account, division, certificate policy, and exact common name. Then require the record’s device.id to match locally. Omit device_group_id from that certificate query because the filter can exclude the registered certificate.

If the original response containing the server-generated private key was lost, stop the complete key-validation path and follow your approved recovery or cleanup procedure. Inventory proves that the device and certificate exist, but it does not prove possession of the matching private key.

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.

• Confirm that every relying party can perform full certificate-path validation, including a reliable clock and reachable revocation endpoints. A constrained device might not be able to evaluate expiry or revocation at all. Where a device cannot, record the compensating control before you finalize certificate lifetimes and the hierarchy design.
• 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.
• Include the successor root certificate in the initial device image or trust store where the relying party cannot be updated in the field. A device that ships with only one trust anchor has no migration path when that anchor is replaced.
• 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 device provisioning

Enroll and verify a device demonstrates certificate issuance using a passcode and a server-generated key. A production device provisioning program must additionally define:

• The device-side client that generates the keypair, submits the certificate signing request (CSR), and renews certificates. DigiCert® TrustEdge provides this as a device agent or a command line tool, and TrustCore SDK supports custom agents.
• Key generation and storage in the device’s secure element. Generate hardware-based private key (TPM2) produces a key that never leaves the TPM.
• The enrollment protocol the device uses. Device Trust Manager supports EST, SCEP, ACME, and CMPv2 in addition to the REST method used in this workflow, and one certificate policy can enable more than one method. Configure an authentication policy when the selected method and deployment require one, and configure device-field mappings for the device attributes the policy needs. See EST enrollment for a CSR-based enrollment example.
• The provisioning credential and the facility that holds it. The enrollment passcode belongs to a provisioning system in a controlled environment. Do not place it in shipped firmware.
• The operational certificate policy and its renewal schedule, where devices move from a bootstrap credential to shorter-lived operational certificates.
• Trust-anchor distribution into the device image, and the relying services the device authenticates to.

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.