Customer certificates
Customer certification practice
How requests, devices and certificates are managed throughout their lifecycle.
Updated 29 October 2026
1. Check the request and approval
For enrollment or renewal, the request identifies the organization, user and certificate purpose. Approval checks the active identity, organization membership and service entitlement. A separate authorized person approves the request for the relevant customer and operation.
When eligibility or the identity binding cannot be verified, the operation remains on hold until the issue is resolved.
2. Prepare the device and key
The subscriber uses a device suited to the approved certificate profile and application. Authentication and document signing have separate keys. Each subscriber private key is created and kept on the device and is not exported or escrowed.
Check the device, proof of possession and the relationship between the request and public key. Before replacing a credential in an occupied location, establish an appropriate replacement or recovery path.
3. Protect device recovery and administration
The user enters the device PIN locally. Each managed device must have unique protected PUK and management-key material, with authority scoped to the customer and device.
Recovery and administrative actions require separate approval, a binding to the device and transaction, and an audit record of the operation. Change device defaults during approved managed-device onboarding.
Rotate recovery or management secrets after approved administrative or recovery use, exposure, or a change in custody or authority, and at managed renewal when feasible. If a device update and its protected record are not both complete, keep the operation pending until they are reconciled.
4. Issue, bind and verify
For an approved request, the issuer uses the approved purpose and profile and binds the certificate to the verified identity and device public key. Check the issued certificate against the request and the target system's identity requirements.
Verify the complete application path, including trust, certificate status and the application's authorization decision.
5. Renew, replace and revoke
For a full 42-day leaf certificate, fresh-key renewal begins on day 31, leaving 11 days in the certificate's actual lifetime. Backdating counts toward the 42-day maximum. Shorter profiles use an earlier schedule; an approved, purpose-specific exception has its own documented duration and schedule.
Renewal rechecks identity, entitlement and approval and requires a new key on the device. The user participates in the necessary device actions. Verify the replacement in the relevant application before routine revocation of the old certificate. Handle suspected compromise promptly through the incident and revocation process.
6. Certificate status and records
Manage certificate, revocation-list and online status information independently for each issuer. Report an unavailable or outdated artifact for the affected issuer while maintaining the other issuers' current information.
Keep audit and validation history according to approved requirements, including the information needed to understand earlier document signatures. The Layer8 status site shows monitored service conditions.
7. Recovery
For a lost, damaged or unavailable device, use the customer's authorized recovery process to verify identity, approve the action and prepare a replacement. Protect the device's recovery and administrative material throughout the operation, and record the action for the customer and device.
Read the certificate policy or return to the customer certificate overview.