Delegation, roles, and access model
Trust Architecture Playbook: Governance pillar
Least privilege
Least privilege in PKI is not simply about preventing unauthorized logins. It's about preventing unauthorized trust. User roles are functional groups of access permissions tied to workflows or job responsibilities, and Trust Lifecycle Manager supports both predefined and custom roles. Permissions include granular capabilities for automation, business units, certificate owners, connectors, network/system scans, reports, audit logs, profiles, templates, enrollments, and certificate lifecycle operations such as renew, revoke, suspend, and resume. Governance should map those permissions to responsibilities and explicitly avoid privilege combinations that create unreviewed issuance paths.
Separate profile creation from certificate request approval where practical.
Separate CA connector administration from day-to-day certificate requesting where practical.
Separate break-glass access from normal operations.
Limit certificate revocation/suspension capabilities to roles with operational need and incident-response procedures.
Require view-only roles for auditors and stakeholders who do not need operational control.
Review high-privilege Trust Lifecycle Manager roles on a defined cadence and immediately after team changes, incidents, or audits.
Business units
Business units are governance segmentation boundaries. They can segment certificate issuance and management by logical or functional criteria, such as locations, teams, functional divisions, policy differences, enrollment methods, or different issuance types. They should be designed around control requirements, not only around the HR organization chart.
Use business units to separate production and non-production where that separation improves control.
Use business units to separate high-risk certificate populations such as public TLS, private server, user/device, mTLS/workload, and lab/test issuance where appropriate.
Avoid one default business unit for the entire enterprise unless the certificate population is small and centrally operated.
Map each business unit to owners, approved profiles, allowed CA sources, and delegated administrators.
Review business-unit seat allocations, profile assignments, and dormant or ownerless assets on cadence.
Service users and automation identities
Service users, API integrations, ACME accounts, connector credentials, CI/CD secrets, and automation identities are PKI actors. They can request, renew, deploy, revoke, or alter trust depending on scope. Governance should treat them as privileged identities, even when they are not human administrators.
Use service users for API and integration access rather than shared human accounts.
Scope service users to required business units, profiles, CA sources, domains/namespaces, and actions only.
Store credentials in approved secret stores or PAM platforms; use secrets manager connectors to make these credentials available for authenticating other connector types in Trust Lifecycle Manager.
Rotate credentials on schedule and after operator departure, incident, or scope change.
Disable unused service users and monitor for dormant credentials that still have issuance capability.
Document owner, purpose, profile scope, expiration/rotation date, and emergency disable path for every automation identity.
Enterprise RA model
A mature enterprise PKI program often separates central policy authority from delegated request validation. Delegated teams can act as enterprise registration authorities (RAs) for specific namespaces, business units, device populations, or application portfolios. That delegation must be explicit, scoped, and reviewable. It should never be based on informal trust that a platform team knows what it is allowed to approve.
Define who may validate a request, which namespace or population they may validate, and which profile they may use.
Require proof of domain, namespace, device, workload, or service ownership before delegation is enabled.
Separate profile creation from certificate request approval where practical.
Require periodic review of delegated authority and immediately revoke delegation when ownership, employment, contract, or system scope changes.
Record approvals in the request system or Trust Lifecycle Manager evidence trail rather than in email-only workflows or out-of-band channels.
Exercise delegated approval through Trust Lifecycle Manager's enrollments function or equivalent request workflow.
Access review checklist
List all users with high-privilege roles including Manager, User and certificate manager, and Certificate profile manager, or custom roles with equivalent permissions.
List all service users and integrations with API or automation access.
Verify business-unit scope, role scope, profile scope, and CA source scope.
Confirm each high-privilege account has a named business owner and technical owner.
Remove access for departed users, changed roles, inactive integrations, expired projects, and decommissioned platforms.
Reconcile role assignments against approvals and exception records.
Record review evidence and remediation actions.