---
title: "Operate this solution"
description: "Prepare, monitor, rotate, recover, and scale the private trust stack."
source_url: https://dev.digicert.com/solutions/private-trust-stack/operate.html
---

# Operate this solution

Prepare, monitor, rotate, recover, and scale the private trust stack.

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](https://dev.digicert.com/md/solutions/private-trust-stack/phase-4-device-enrollment.md#phase-4-checkpoint) and [code signing](https://dev.digicert.com/md/solutions/private-trust-stack/phase-5-code-signing.md#phase-5-checkpoint).
- [ ] 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](https://dev.digicert.com/md/solutions/private-trust-stack/reference.md#implementation-status-and-saved-values) are retained.
- [ ] The [approved root fingerprint](https://dev.digicert.com/md/solutions/private-trust-stack/phase-2-private-trust-anchor.md#step-23-download-and-validate-the-ca-certificates) 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](https://dev.digicert.com/md/get-started/authentication.md#best-practices-for-service-users-and-api-tokens), and separate credentials by workload and environment:

| Identity | Typical capabilities | Production use |
|----------|----------------------|-------------|
| CA setup identity | Configure CA assignments, templates, profiles, policies, and groups. | Disable or tightly restrict after setup. |
| Device enrollment identity | Request and manage device certificates only. | Device provisioning or fleet service. |
| Software signing identity | Access approved keypairs and sign with multi-factor authentication. | Build or release pipeline. |

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:

| Signal | Source | Recommended alert |
|--------|--------|-------------------|
| Service-user and API token state and expiry | [Account Manager API token and user endpoints](https://dev.digicert.com/md/account-manager-api/tutorials/manage-api-token-lifecycle.md#endpoint-overview) | Disabled, deleted, or within the approved renewal window. |
| Client authentication certificate state and expiry | [`GET /account/api/v1/client-auth-certificate`](https://dev.digicert.com/md/account-manager-api/tutorials/set-up-service-user-multi-factor-authentication.md#check-certificate-expiration) | Disabled or 30 days before expiry. |
| Root and issuing-CA validity | [Downloaded CA certificates](https://dev.digicert.com/md/solutions/private-trust-stack/phase-2-private-trust-anchor.md#step-23-download-and-validate-the-ca-certificates) and DigiCert Private CA inventory | 180-day, 90-day, and 30-day thresholds appropriate to the CA-renewal process. |
| Certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP) publication and reachability | DigiCert Private CA revocation infrastructure | Missing, stale, or unreachable distribution point. |
| Device enrollment result | Certificate issuance response and request-status endpoint | Any sustained failure or unexpected approval state. |
| Issued device-certificate validity and revocation | Device Trust Manager inventory | Expiry threshold, revocation, or unexpected issuer or profile. |
| Signing authentication and policy failures | Software Trust Manager response and audit events | Any unexpected multi-factor authentication, authorization, approval, or release-window failure. |
| Signing certificate and keypair state | Software Trust Manager inventory | Offline key, missing default certificate, revocation, or approaching expiry. |

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](https://dev.digicert.com/md/account-manager-api/tutorials/manage-api-token-lifecycle.md) 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.
1. Create a new API token with an approved name and expiration:

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

1. Store the returned token directly in your approved secret manager.
1. Deploy the new token to one integration instance while retaining the old token for rollback.
1. Verify account access, device enrollment, and signing as applicable.
1. Shift all traffic to the new token.
1. 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](https://dev.digicert.com/md/account-manager-api/tutorials/set-up-service-user-multi-factor-authentication.md#client-certificate-expiration-and-rotation) for the complete certificate-management workflow.

1. Create a replacement certificate for the existing service user in Account Manager.
1. Deploy the new certificate and private key with the active API token.
1. Verify a protected signing operation.
1. 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](https://dev.digicert.com/md/solutions/private-trust-stack/phase-4-device-enrollment.md#step-42-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.
1. Update the enrollment clients to use the new passcode.
1. Verify enrollment with the new passcode.
1. 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](https://dev.digicert.com/md/get-started/error-handling-rate-limits.md). 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](https://dev.digicert.com/md/solutions/private-trust-stack/phase-4-device-enrollment.md#if-enrollment-requires-approval). The initial enrollment response reports `PENDING_APPROVAL` and contains `certificate_request_id`. Poll:

```text
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](https://dev.digicert.com/md/solutions/private-trust-stack/phase-2-private-trust-anchor.md#step-23-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](https://dev.digicert.com/md/device-trust-api/api-reference.md#/operations/batchDeviceRegistration) 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](https://dev.digicert.com/md/software-trust-api/api-reference.md#/paths/api-v1-keypairs-keypair-id--batch-sign/post) 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](https://dev.digicert.com/md/get-started/environments-base-urls.md#start-with-demo) using representative payload sizes and approval behavior before production rollout.

## Production signing

[Sign and verify a known hash](https://dev.digicert.com/md/solutions/private-trust-stack/phase-5-code-signing.md#step-55-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](https://dev.digicert.com/md/solutions/private-trust-stack/troubleshoot.md).
- [Look up implementation status, identifiers, and request formats](https://dev.digicert.com/md/solutions/private-trust-stack/reference.md).
- [Return to the solution overview](https://dev.digicert.com/md/solutions/private-trust-stack.md).