Customer certificates
Customer certificate policy
Who can receive a customer certificate and the rules for its use and care.
Updated 29 October 2026
Purpose and authority
This policy sets the eligibility, permitted uses and lifecycle rules for customer certificates. Authentication and document signing use separate issuing authorities and separate subscriber keys.
The customer root and policy authorities establish the authority hierarchy. Each issuing authority serves its approved purpose. Access also requires the relevant application authorization.
Eligibility and approval
Issuance and renewal require an active identity and membership in the relevant organization, the service entitlement and an authorized purpose. A separate authorized person approves each request; a requester cannot approve their own certificate.
Identity and membership are checked against the applicable source. An email address, an existing certificate or a familiar name alone is not sufficient. A request remains on hold when eligibility or the identity binding cannot be verified.
Keys, devices and permitted use
Authentication and document-signing private keys are distinct. Subscriber private keys are generated and kept on the subscriber's device; they are not exported or escrowed. Each certificate is used for its approved purpose and profile.
New L8DT-controlled production RSA keys have a minimum size of 4096 bits. Approved profiles may use P-384 elliptic-curve keys when the device and application support them.
Device care and recovery authority
The user enters the device PIN locally. Each managed device must have its own protected PUK and management-key material, with recovery authority limited to the relevant customer and device.
Recovery and administrative actions require separate approval and an audit record of the operation. Rotate recovery and management secrets after approved use, exposure or a change in custody or authority, and at managed renewal when feasible.
Validity and fresh-key renewal
A production leaf certificate has an actual lifetime of no more than 42 days, including any backdating. For a full 42-day certificate, fresh-key renewal begins on day 31, leaving 11 days in its lifetime. Shorter profiles use an earlier schedule.
Renewal requires a new private key, current eligibility and the necessary user and device participation. An approved, purpose-specific exception has its own documented duration and renewal schedule.
Replacement and revocation
For routine replacement, verify that the new certificate works in the relevant application before revoking the superseded certificate. Report suspected compromise promptly and follow the appropriate incident response and revocation process.
Applications check certificate validity and revocation according to their trust configuration. Preserve the audit and validation history needed to account for certificates and earlier document signatures.
Trust and recovery
Each issuer has its own certificate and revocation status information. Customers establish trust in the systems that use their certificates and check the relevant application and device during enrollment and renewal.
Recovery actions follow the customer's authorized device and identity procedures, with a separate approval and an operation record. Read the certification practice or return to the customer certificate overview.