PKIaaS for Platform Engineering Teams: Self-Service Certificates with Governance

Self-service certificate issuance sounds like it should be straightforward: developers request certificates, they get them, the PKI team is not involved in every transaction. The concern that prevents most organizations from implementing it is certificate sprawl: if developers can get certificates freely, the security team loses visibility into what has been issued, naming conventions break down, validity periods go uncontrolled, and the certificate estate that automation was supposed to simplify becomes more chaotic than the manual process it replaced.

The answer is not to avoid self-service. It is to build self-service on top of a governance model that makes sprawl technically impossible rather than just policy-discouraged. Certificate profiles that define what can be issued. SAN allowlists that define valid naming. RBAC that separates who can issue from who can administer. Enrollment approval workflows that gate non-automated requests. Audit logs that surface every issuance event regardless of the channel used. Expiration controls that prevent long-lived certificate accumulation. This post explains each governance layer and how they work together to make PKI as a Service self-service safe for technical decision makers who cannot accept a sprawl problem in exchange for developer convenience.

Quick Answer: How Do You Get Self-Service Without Sprawl?

Self-service without sprawl requires five governance controls working together. Certificate profiles define the technical envelope of what can be issued, enforced at the CA before any certificate is signed. SAN allowlists restrict which names can appear in issued certificates. RBAC separates the roles that define policy from the roles that execute issuance. Enrollment workflows define the approval path for each certificate type, automating approval for low-risk requests and routing high-risk requests through a human review step. Audit logs provide complete visibility into every issuance event across all teams and enrollment channels. With all five in place, self-service is controlled issuance, not uncontrolled issuance.

Key Takeaways

• Certificate profiles are the primary governance control in PKIaaS. A profile is a named set of constraints on what the CA will issue: key algorithms, minimum key sizes, EKU OIDs, maximum validity period, and SAN types. Every certificate request references a profile. Every certificate issued conforms to the referenced profile’s constraints. It is technically impossible to issue a certificate that violates the profile, regardless of which enrollment interface the requester uses.
• SAN allowlisting prevents naming sprawl. An allowlist specifies which SAN values or SAN value patterns are permitted for certificates issued to a given team or namespace. A developer cannot request a certificate for a name that does not match the allowlist. This prevents accidental cross-team domain ownership conflicts, phishing-enabling certificate issuance, and naming convention violations that auditors flag during certificate estate reviews.
• Role separation is as important as technical controls. A governance model where the same person defines certificate profiles, issues certificates, and reviews the audit log has no effective checks on policy-level decisions. Separating the CA Administrator role (who defines policy) from the Certificate Administrator role (who issues within policy) from the CA Auditor role (who reviews issuance records) enforces the principle of least privilege at the administrative level, not just at the certificate level.
• Not all certificate requests should be automated. Automated enrollment (ACME, SCEP, MDM autoenrollment, WSTEP) is appropriate for certificate types that conform to a well-defined, machine-verifiable profile. Certificate requests that involve unusual validity periods, non-standard naming, high-privilege EKU OIDs (code signing, smart card logon), or names outside the standard allowlist should route through a human approval workflow. PKIaaS enrollment workflows support both paths from the same CA backend.
• Policy-as-code is the mature implementation of PKIaaS governance. Certificate profile definitions, SAN allowlists, RBAC role assignments, and enrollment workflow configurations maintained as version-controlled code, deployed through a reviewed change management process, and auditable by commit history produce a governance model that can be examined by auditors, reviewed by legal counsel, and reproduced from source control after any configuration incident.

What Certificate Sprawl Looks Like in Practice

Certificate sprawl is not a theoretical risk. It is what happens when certificate issuance is convenient but ungoverned. A team needs a certificate for a new service; the fastest path is a self-signed certificate committed to the repository. Another team is blocked on the PKI request queue; they spin up an internal CA on a development server, never formally decommission it, and three years later nobody knows which services trust it. A developer tests an ACME client against the production endpoint and accidentally issues a 1-year certificate for a dev subdomain that goes into the certificate database with no associated owner. A migration project leaves 200 certificates on a legacy CA that is never decommissioned because nobody can confirm whether any active service still relies on those certificates.

Every one of these scenarios produces the same result: certificates in the environment that no team owns, no system tracks, no CLM platform monitors, and no renewal process covers. The DigiCert Trust Pulse Survey (July 2, 2025) found that 45% of enterprises experienced certificate-related downtime and 37.5% traced that downtime to an expired certificate. Most of those expired certificates were not forgotten by teams that were careless; they were forgotten by teams that never had a governed process for tracking them in the first place.

Self-service PKI solves the wrong half of this problem if it only adds a convenient issuance channel without adding the governance controls that produce a trackable, policy-compliant certificate estate. The right model adds both: a self-service interface that developers can actually use, and governance controls that make the resulting certificate estate auditable, compliant, and operationally manageable.

Governance Control 1: Certificate Profiles

A certificate profile is the technical enforcement of certificate policy at the CA layer. Every certificate request references a profile. The CA validates the request against the profile’s constraints before signing. A request that violates any constraint is rejected at the CA, before a certificate is issued, regardless of whether the requester authenticated successfully.

A well-designed profile for a specific certificate category specifies:

• Permitted key algorithms and minimum key sizes. For example, ECDSA P-256 or P-384, or RSA-2048 minimum. Requests with RSA-1024 keys or non-permitted algorithms are rejected.
• Extended Key Usage OIDs. A service TLS profile permits Server Authentication (OID 1.3.6.1.5.5.7.3.1) and optionally Client Authentication (OID 1.3.6.1.5.5.7.3.2). A code signing profile permits Code Signing (OID 1.3.6.1.5.7.3.3). A smart card logon profile permits Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication. Requests for a profile with EKU OIDs that would grant high-privilege capabilities (like code signing) through a low-privilege enrollment path are impossible to construct because the profile only permits the intended EKU set.
• Subject field rules. Whether the requester can supply the Common Name, whether the O and OU fields are CA-populated from the organization record, and what format the CN must take (for example, must be a fully qualified domain name, must match a specific pattern, must be populated from an LDAP attribute).
• SAN types permitted. Whether the profile permits DNS SANs only, or also IP SANs, URI SANs (for SPIFFE-style workload identity), UPN SANs (for smart card logon), or RFC 822 email SANs (for S/MIME). A profile that permits only DNS SANs cannot be used to issue a certificate with an IP SAN, even if the requester includes one in the CSR.
• Maximum certificate validity. The CA refuses to issue a certificate with a validity period exceeding the profile’s maximum, even if the requester specifies a longer period in the enrollment request. This prevents long-lived certificate accumulation through the self-service channel.

For enterprise PKIaaS deployments, the profile set should map to the organization’s certificate categories: an internal service TLS profile, an mTLS client authentication profile, a user smart card profile, an S/MIME profile, a code signing profile, and a CI/CD pipeline identity profile. Each profile is defined by the CA Administrator role and cannot be modified by the Certificate Administrator role or the enrollment automation layer. Profile changes go through the same change management process as any security-relevant configuration change.

Subscriber certificate profiles in a well-designed PKIaaS implementation are distinct from authority certificate profiles (which govern the CA certificates themselves) and can be customized per deployment to enforce organization-specific constraints that go beyond the protocol-level defaults for each enrollment type.

Governance Control 2: SAN Allowlists

Subject Alternative Name allowlists are a CA-level control that restricts which names can appear in certificates issued under a given CA or profile. The allowlist is maintained by the CA Administrator, not by the certificate requester. A certificate request that specifies a SAN not matching the allowlist is rejected before any certificate is signed.

SAN allowlists serve several governance functions simultaneously. They enforce naming conventions: if the organization’s naming policy says that internal service certificates must use names in the *.internal.example.com domain, the SAN allowlist for the internal service TLS profile restricts DNS SANs to that pattern. A request for a certificate with a SAN of api.external-partner.com is rejected, even if the requester is authenticated and the profile is otherwise valid.

They prevent cross-team naming conflicts: if Team A owns the payments.internal.example.com name and their team’s SAN allowlist is scoped to *.payments.internal.example.com, Team B cannot request a certificate for a name in Team A’s namespace through the self-service channel, even if both teams are authorized to use the same certificate profile.

They provide a traceable record of approved names: the SAN allowlist is an explicit registry of which names the organization has decided to issue certificates for. Additions to the allowlist go through the CA Administrator’s change management process, creating a documented approval trail for name authorization.

For Kubernetes-based deployments, SAN allowlisting at the PKIaaS CA layer complements cert-manager’s CertificateRequestPolicy at the Kubernetes layer. The Kubernetes layer enforces the namespace-level naming constraint before the CSR reaches the CA; the CA-level SAN allowlist is a defense-in-depth control that would catch any request that somehow bypassed the Kubernetes policy layer.

Governance Control 3: Role-Based Access Control

Role separation in PKIaaS governance is the administrative equivalent of the separation of duties principle applied to certificate operations. The roles must be designed so that no single person can both define what the CA will issue and issue certificates outside those definitions, and no single person can issue certificates and then prevent those issuances from appearing in the audit log.

A production PKIaaS deployment should have at minimum the following role categories, held by different named individuals with different reporting chains:

CA Owner / CA Administrator. Creates and configures the CA hierarchy, defines and modifies certificate profiles, manages SAN allowlists, configures enrollment workflows, and manages role assignments for other users. This role must not be assigned to anyone who routinely issues certificates for operational workloads. In practice, this role is held by the PKI Architect or Security Engineering Lead responsible for the PKI program.

Certificate Administrator. Issues, renews, and revokes certificates within the profiles and SAN allowlists that the CA Administrator has configured. Cannot modify profiles, SAN allowlists, or CA configuration. For automated enrollment (ACME, SCEP, MDM), this role is held functionally by the service accounts or API credentials used by the enrollment automation. For manual issuance (eForm TLS approval workflows), this role is held by PKI operations team members who review and approve certificate requests.

CA Auditor. Read-only access to all certificate issuance records, enrollment workflow event logs, and audit trails. Cannot issue or revoke certificates. Cannot modify any configuration. The Auditor role is held by the security operations team, the compliance team, or external auditors who need visibility into certificate activity without operational access. The key governance property of this role is independence: the Auditor can see everything that has been issued and cannot be blocked from seeing it by anyone with operational access.

Enrollment Workflow Administrator. Configures the automated enrollment workflows (ACME endpoint creation, SCEP profile configuration, MDM workflow setup, WSTEP agent configuration) but does not hold certificate issuance authority directly. This role is held by the platform engineering team that wires enrollment automation into the IDP. Separating Enrollment Workflow Administration from CA Administration means that the team building the automation integration cannot modify the profiles or allowlists that govern what the automation can request.

Enrollment Workflow Auditor. Read-only access to enrollment workflow events and their associated issuance logs. Used by teams that need visibility into enrollment automation behavior without broader access to the CA configuration.

Role assignments should be managed through the organization’s identity provider (Azure AD, Okta, or equivalent), not through local PKIaaS user accounts where possible. IdP-managed role assignments produce a role assignment audit trail in the IdP’s access log, are governed by the organization’s joiner/mover/leaver process, and are visible to the IAM team alongside all other access assignments.

Governance Control 4: Enrollment Workflows and Approval Gates

Enrollment workflows are the decision layer that determines how a certificate request is processed: automatically approved and issued, routed to a human approver, or rejected outright. The design of the enrollment workflow for each certificate type is one of the most important governance decisions in a PKIaaS deployment because it determines which requests bypass human review and which are subject to it.

For most certificate types in a well-configured PKIaaS deployment, the workflow is automated: the enrollment request arrives (via ACME, SCEP, MDM, or WSTEP), the CA validates it against the profile and SAN allowlist, and if it passes, the certificate is issued without human review. This is the right model for service TLS certificates, mTLS client certificates, MDM-enrolled device certificates, and Kubernetes workload certificates. The profile and allowlist constraints make every automated issuance a governed issuance; human review of individual requests adds no additional security value when the policy is already enforced technically.

Some certificate types should route through a manual approval workflow. A web-form-based enrollment workflow (sometimes called an eForm workflow in PKIaaS implementations) presents the request to a Certificate Administrator who reviews it before it is issued. The reviewer can inspect the requested subject, the SANs, the profile referenced, and the requesting party’s identity. They approve the request if it is appropriate, reject it with an explanation if it is not, or escalate it to the CA Administrator if it requires a policy exception. This approval path is appropriate for: certificates with extended validity periods beyond the standard profile maximum; certificates for names that are not in the SAN allowlist but may warrant a policy exception; code signing certificates and smart card logon certificates, which carry elevated privilege and warrant human review even when the technical parameters are within the profile; and certificate requests from external parties or contractors who do not have automated enrollment configured.

The enrollment workflow architecture should make the approval path clear and auditable: every request that goes through the manual approval flow should have a logged decision (approved/rejected/escalated), the identity of the reviewer, and the timestamp of the decision. This produces a human decision trail for non-standard certificate requests that complements the automated issuance audit trail for standard requests.

Governance Control 5: Audit Logs and Continuous Visibility

The audit log is what makes a self-service PKI program auditable rather than merely convenient. Every certificate issuance event, regardless of the enrollment channel, must be recorded with: the issuing CA, the certificate profile used, the subject and SANs of the issued certificate, the requesting identity (the ACME client service account, the MDM enrollment credential, the eForm requester, or the API credential used), the timestamp, and the approval decision if the request went through a manual workflow.

An audit log that covers only manually issued certificates and not automated ACME or MDM issuances is not an audit log; it is a partial record. PKIaaS deployments should audit all enrollment channels uniformly. The CA Auditor role should have access to the complete issuance record across all channels, not just the records from the channels the auditor already knows about.

For compliance purposes, the audit log must be tamper-evident and retained for the relevant period. Many compliance frameworks specify audit log retention requirements: SOC 2 typically requires one year; some regulated industry frameworks require longer. The PKIaaS audit log should be exported to a SIEM or secure log archive regularly, so that the log is preserved independently of the PKIaaS platform and would survive a PKIaaS configuration incident that overwrites or corrupts the live audit log.

Beyond compliance, the audit log is the operational tool for certificate governance: the CLM platform connected to the PKIaaS CA can alert on unusual issuance patterns (a spike in certificate requests from a specific team, requests for names outside the expected pattern, repeated rejection events that might indicate someone probing the enrollment API), and the auditor can investigate specific issuance events when a security incident requires tracing which certificate was used in a specific authentication event.

Governance Control 6: Expiration Policy and Lifecycle Enforcement

Long-lived certificates are the most common cause of certificate sprawl accumulation. A certificate issued with a 5-year validity period and no automated renewal will be in the environment for 5 years. After the first 6 months, it is likely that the person who requested it has changed roles or left the organization, the system it was provisioned for has been updated or replaced, and the team that owns it does not remember it exists. By year 3, the certificate is orphaned: nobody is monitoring it, no renewal is planned, and when it expires, whatever system is still using it will fail without warning.

Expiration policy enforced at the CA profile level prevents this accumulation. A profile with a 90-day maximum validity period cannot be used to issue a 2-year certificate, regardless of what the requester specifies. The profile’s maximum validity is the ceiling; the requester can request a shorter validity but not a longer one. Combining this with automated renewal (cert-manager for Kubernetes workloads, ACME renewal for Linux services, MDM-triggered renewal for devices) means that certificates with short validity periods and automated renewal are operationally sustainable: the renewal happens automatically before the certificate expires, and the CLM platform alerts if an expected renewal does not occur.

For certificate types that do not have automated renewal (manually issued certificates for legacy systems or external partners), a CLM platform connected to the PKIaaS CA should alert owners at defined intervals before expiry (90 days, 60 days, 30 days). The alert should route to the named certificate owner, not to a generic PKI team mailbox that may not know which specific system the certificate serves. Certificate ownership should be recorded at issuance time, either in the PKIaaS metadata fields or in the CLM platform’s inventory, so that expiry alerts reach the right team.

Bulk revocation is the emergency expiration control: when a certificate type issued by a specific CA or a specific profile needs to be revoked fleet-wide (for a CA compromise, a key algorithm deprecation, or a profile misconfiguration), PKIaaS bulk revocation capabilities allow all matching certificates to be revoked in a single operation. The resulting CRL and OCSP updates propagate to all relying parties within the normal CRL validity window, and the CLM platform surfaces the revocation events as a bulk action in the audit log.

Policy-as-Code: The Mature Governance Implementation

Most PKIaaS implementations begin with governance controls configured through the management console: a security engineer logs in, creates a certificate profile, sets the SAN allowlist, assigns roles, and saves. This is workable but produces a governance model that exists only in the PKIaaS platform’s configuration database, not in any version-controlled, reviewable, reproducible form. If the configuration is changed (correctly or incorrectly), the previous configuration is not preserved for review. If an auditor asks what profile constraints were in effect on a specific date, the answer may not be available.

Policy-as-code matures this model by managing PKIaaS configuration through the same infrastructure-as-code practices applied to the rest of the platform: profile definitions, SAN allowlists, role assignments, and enrollment workflow configurations are stored as YAML or JSON in a version-controlled repository, changes are proposed as pull requests that go through peer review before being merged, and a CI/CD pipeline deploys approved changes to the PKIaaS CA through the REST API.

This approach produces several governance benefits simultaneously. Every configuration change has a documented review trail (the pull request, the reviewer approvals, the merge timestamp). Every past configuration state is retrievable from version history (if an auditor asks what the profile constraints were in Q3 of last year, the repository shows the profile configuration as it was at any point). Configuration drift is detectable: the current PKIaaS configuration can be compared to the repository’s expected configuration as part of a continuous compliance check, and any divergence (a profile changed outside the IaC process) surfaces as an alert.

For Kubernetes deployments, cert-manager’s CertificateRequestPolicy resources are already Kubernetes manifests in the GitOps repository, so the policy-as-code pattern applies naturally. For the PKIaaS CA configuration itself, the PKIaaS REST API provides the programmatic interface that IaC tooling uses to deploy and update profiles, allowlists, and workflow configurations from the repository.

Multi-Tenant Governance for Platform Teams

Platform engineering teams serving multiple internal customers (application development teams, data engineering teams, security operations teams, infrastructure teams) face an additional governance challenge: different teams have different certificate requirements, different risk profiles, and potentially different compliance obligations, but they all share the same PKIaaS CA infrastructure.

PKIaaS partition-based multi-tenancy addresses this: each tenant team operates within a PKIaaS partition that has its own certificate profile set, its own SAN allowlist, its own role assignments, and its own audit log. The CA Administrator for the overall platform can see all partitions; the Certificate Administrator for a specific team can only see and issue certificates within that team’s partition. This produces per-team governance isolation without requiring separate CA infrastructure for each team.

The platform team’s governance responsibility in a multi-tenant PKIaaS deployment is to design the partition structure, define the default profile set that applies across all tenants, and create the process for tenant-specific profile customization requests (which go through the CA Administrator’s change management process). Individual tenant teams are responsible for their SAN allowlist management (within the constraints the platform team sets) and their Certificate Administrator role assignments (within their partition).

This governance model scales to large enterprise deployments without creating a PKI team bottleneck: each tenant team has operational autonomy within their partition, while the platform team maintains policy governance at the CA and profile level. The CA Auditor role spans all partitions, giving the security team complete visibility across the organization’s certificate estate regardless of which partition issued a specific certificate.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA infrastructure with the full governance control set described in this post: certificate profiles with configurable constraints (key algorithms, EKU OIDs, maximum validity, SAN types), SAN allowlisting, role-based access control with Owner/CA Administrator/Certificate Administrator/CA Auditor/Enrollment Workflow Administrator/Enrollment Workflow Auditor role separation, enrollment approval workflows for manual issuance paths, and per-enrollment-channel audit logging. Contact us at Encryption Consulting to discuss your PKIaaS governance requirements.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM visibility layer that the governance model requires: unified certificate inventory across all enrollment channels and CA partitions, expiry monitoring with named-owner alerting, policy compliance reporting (surfacing certificates that violate the current profile constraints, indicating profile configuration drift or legacy certificates from before governance controls were implemented), and SIEM integration for audit log export and anomalous issuance pattern alerting.
• PKI Assessment Service: For organizations designing a PKIaaS governance model from scratch, or assessing an existing self-service PKI program for governance gaps, Encryption Consulting’s PKI Assessment Service evaluates the current certificate profile design, role assignment model, enrollment workflow configuration, and audit log coverage against the governance framework described in this post, and produces a gap analysis and implementation roadmap.
• PKI Services (CP/CPS Development): The governance controls in a PKIaaS deployment must be documented in a Certificate Policy and Certification Practice Statement that auditors, regulators, and relying parties can review. Encryption Consulting’s PKI Services include CP/CPS development that documents the profile constraints, role model, enrollment workflow design, and audit log practices in the format required by SOC 2, WebTrust, FedRAMP, and other compliance frameworks.
• Compliance Advisory Services: For organizations subject to DORA, NIS2, HIPAA, FedRAMP, or CMMC compliance requirements, the PKIaaS governance model must satisfy specific requirements around certificate policy documentation, audit log retention, role separation evidence, and change management for CA configuration. Encryption Consulting’s Compliance Advisory Services map the PKIaaS governance design against each applicable compliance framework and produce the evidence package that demonstrates governance compliance to auditors and regulators.

Conclusion

Self-service certificate issuance is achievable without certificate sprawl. The five governance controls described in this post, certificate profiles, SAN allowlists, RBAC role separation, enrollment approval workflows, and audit logs, when implemented together, make the self-service channel a governed issuance channel rather than an uncontrolled one. Certificate sprawl is a governance failure, not a consequence of self-service. Organizations that implement self-service without governance get sprawl. Organizations that implement governance alongside self-service get both developer convenience and an auditable, policy-compliant certificate estate.

The maturity progression for PKIaaS governance typically runs: profiles and allowlists first (the technical controls that enforce the policy envelope), then role separation (the administrative controls that prevent policy bypass), then enrollment workflow design (the approval controls that gate non-standard requests), then policy-as-code (the change management controls that make the policy reviewable and auditable by commit history), and finally multi-tenant partition design (the structural controls that scale governance across multiple teams without centralized bottlenecks). Organizations at any point in this progression are materially better governed than organizations with no controls at all; the maturity progression is a path to follow, not a prerequisite to achieve before deploying self-service.

If your organization is evaluating PKIaaS governance design or reviewing the controls on an existing self-service certificate program, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when CA/B Forum Baseline Requirements, SOC 2 Trust Service Criteria, or major compliance frameworks publish updates that affect certificate policy documentation or audit log requirements.

Frequently Asked Questions

What is certificate sprawl and how does self-service PKI cause it?

Certificate sprawl is the accumulation of certificates that no team owns, no system tracks, and no process renews. Self-service PKI causes it when it provides a convenient issuance channel without governance controls: no profile constraints defining what can be issued, no SAN allowlists defining valid naming, no audit trail surfacing what has been issued, and no CLM layer monitoring expiry. The solution is not to eliminate self-service but to add governance controls that make every self-service issuance a governed issuance.

What is a certificate profile in PKIaaS and how does it enforce policy?

A certificate profile is a named configuration defining the permitted parameters for a certificate category: key algorithms, minimum key sizes, Extended Key Usage OIDs, SAN types, subject field rules, and maximum validity period. Every certificate request references a profile. The CA validates each request against the profile’s constraints before signing. A request violating any constraint is rejected at the CA before a certificate is issued, regardless of the enrollment channel or the requester’s authentication status.

What RBAC roles should exist in a PKIaaS governance model?

At minimum: CA Owner/Administrator (creates profiles, manages SAN allowlists, configures workflows, cannot routinely issue certificates), Certificate Administrator (issues within configured profiles, cannot modify profiles), CA Auditor (read-only access to all issuance records, cannot issue or configure), and Enrollment Workflow Administrator (configures automated enrollment, cannot modify profiles or SAN allowlists). Separating these roles ensures no single person can both define policy and issue outside it, and no operational user can suppress their own audit trail.

What is a SAN allowlist in PKIaaS and why is it a governance control?

A SAN allowlist specifies which Subject Alternative Name values or patterns the CA will accept for a given profile or CA. Requests with SANs not matching the allowlist are rejected before a certificate is signed. This prevents naming convention violations, cross-team domain ownership conflicts, and issuance for names the organization has not explicitly approved. Allowlist changes go through the CA Administrator’s change management process, creating a documented approval trail for name authorization.

How does policy-as-code work for certificate governance?

Policy-as-code stores certificate profile definitions, SAN allowlists, RBAC role assignments, and enrollment workflow configurations as version-controlled files in a repository. Changes are proposed as pull requests with peer review, and a CI/CD pipeline deploys approved changes to the PKIaaS CA via the REST API. This produces a reviewable change trail (pull request history), retrievable historical configuration (version history for any past date), and drift detection (current CA configuration compared to repository expectation as a continuous compliance check).