PKIaaS for Internal Developer Platforms

Platform engineering teams get asked for the same thing repeatedly, in different forms. Developers need TLS certificates for their services. CI/CD pipelines need credentials that are not hardcoded API keys. Kubernetes workloads need mTLS identities. The security team needs all of this to happen with consistent policy, auditable issuance, and no manual PKI team involvement in every request. The answer the platform team reaches for is usually a service account, a shared certificate, or a self-signed cert script committed to the repository. None of these are the right answer.

The right answer is PKIaaS as a platform capability: the platform team wires a governed certificate authority into the IDP once, exposes it through ACME, cert-manager, and an API, and developers get self-service certificate issuance that automatically enforces the security team’s policies without the developer needing to know what a certificate profile is. This post explains how to build that capability.

Quick Answer: What Does PKIaaS Look Like as an IDP Capability?

PKIaaS becomes an IDP capability when the platform team configures the PKIaaS CA backend, defines certificate profiles for each workload type, and exposes those profiles through the platform’s standard interfaces: a cert-manager ClusterIssuer for Kubernetes workloads, an ACME endpoint with OIDC authentication for CI/CD pipeline jobs, a Terraform provider module for infrastructure-as-code consumers, and a Backstage service catalog template for teams that prefer a UI-based request flow. Developers request certificates through the interface they already use. The PKIaaS CA enforces the platform team’s certificate policy without any developer-facing complexity. The CLM layer gives the security team audit visibility into the entire certificate estate across all platform tenants.

Key Takeaways

• Platform teams are the right owners of certificate issuance policy, not application developers. The platform team sets the guardrails once (valid certificate profiles, naming constraints, validity period limits, key algorithm minimums). Developers request within those guardrails without knowing the guardrails exist. This is the same paved-road model that platform teams apply to container base images, Terraform modules, and observability configurations.
• cert-manager is the Kubernetes interface between developer workloads and the PKIaaS CA. The platform team deploys cert-manager and configures a ClusterIssuer pointed at the PKIaaS ACME endpoint. Developers declare Certificate resources in their Kubernetes manifests; cert-manager handles issuance, storage as Kubernetes Secrets, and automatic renewal. No developer interaction is required after the initial declaration.
• OIDC token exchange makes CI/CD pipeline certificates possible without pre-shared secrets. Modern CI/CD platforms (GitHub Actions, GitLab CI, CircleCI) issue OIDC tokens to pipeline jobs that can be exchanged for short-lived PKIaaS certificates through the ACME External Account Binding mechanism. The pipeline job’s certificate is valid only for the job’s duration and expires automatically. No secrets rotation is required.
• Certificate request templates remove the expertise requirement from developer-side certificate requests. Templates define the valid subject naming patterns, SAN types, validity periods, and key usage for each certificate category. Developers select a template; the platform enforces the template constraints. Developers never need to know what an Extended Key Usage OID is or what the CA/B Forum’s Baseline Requirements say about SAN formatting.
• The CA/B Forum SC-081v3 47-day maximum validity schedule (effective March 15, 2029) makes automated renewal mandatory for all public TLS certificates. Platform teams that build PKIaaS-backed automated renewal into the IDP now are building the compliance solution before the deadline arrives, not scrambling to retrofit automation across a manually managed certificate estate.

The Platform Engineering Problem with Certificates

Platform teams face a specific version of the certificate management problem that differs from the enterprise-wide certificate management problem security teams face. Security teams worry about the full certificate estate: discovery, inventory, policy compliance, expiry monitoring across all certificates from all sources. Platform teams worry about a narrower but more operationally immediate problem: how do developers get certificates for their workloads without creating a queue at the PKI team’s inbox, without committing secrets to repositories, and without producing a certificate estate that is impossible to manage at scale?

The patterns that platform teams reach for when PKIaaS is not available all have the same failure mode: they optimize for developer convenience at the cost of security and operational manageability. Wildcard certificates shared across services eliminate per-service certificate management but also eliminate per-service isolation: one compromised service can use the wildcard to impersonate any other. Self-signed certificates eliminate the PKI team bottleneck but also eliminate the chain of trust that makes mTLS meaningful. Long-lived service account credentials provide a workable stopgap but accumulate as technical debt: they require rotation events that are difficult to coordinate across a large developer organization.

PKIaaS as an IDP capability eliminates these trade-offs. Developer convenience is provided by the self-service interface (a cert-manager Certificate resource, a Terraform module call, a Backstage template). Certificate security is provided by the PKIaaS CA (FIPS 140-3 Level 3 HSM-backed keys, policy-governed issuance, automatic expiry). Operational manageability is provided by the CLM layer (unified inventory, automated renewal, policy compliance monitoring). The platform team configures the integration once; developers use it forever.

Kubernetes Integration: cert-manager as the IDP Interface

For platform teams running Kubernetes-based IDPs, cert-manager is the standard interface between developer workloads and the PKIaaS CA. The integration architecture has three layers that the platform team configures once.

ClusterIssuer Configuration

The platform team installs cert-manager in each cluster and creates a ClusterIssuer (or multiple namespace-scoped Issuers for multi-tenant clusters with different certificate policies per tenant) that points at the PKIaaS ACME endpoint. The ClusterIssuer configuration specifies the ACME server URL, the External Account Binding (EAB) key ID and HMAC secret issued by the PKIaaS CA for this cluster, and the DNS or HTTP challenge configuration for domain validation. For internal services using private DNS (which is the typical case in an enterprise Kubernetes environment), DNS-01 challenge against the organization’s internal DNS provider is the appropriate challenge type.

Once the ClusterIssuer is configured and validated, every Certificate resource in every namespace can reference it as the issuer. The platform team controls which namespaces can use which issuers through cert-manager’s CertificateRequestPolicy (the cert-manager policy approver component) combined with Kubernetes RBAC. An application namespace might be restricted to requesting certificates with SANs matching the namespace’s assigned domain pattern; a system namespace might have access to a different issuer that permits infrastructure-specific certificate types.

Developer-Facing Certificate Resources

From the developer’s perspective, requesting a certificate in the Kubernetes IDP looks like this: declare a Certificate resource in the service’s Helm chart or Kustomize overlay specifying the desired subject and SANs, reference the platform-provided ClusterIssuer, and deploy. cert-manager creates a CertificateRequest, submits the CSR to the PKIaaS ACME endpoint, completes the domain validation challenge, retrieves the signed certificate, and stores it as a Kubernetes Secret. The application references the Secret in its Pod spec as a volume mount or environment variable. The certificate appears in the running Pod within seconds of the Certificate resource being applied.

When the certificate approaches its renewal threshold (cert-manager’s default is to renew when two-thirds of the validity period has elapsed), cert-manager automatically requests a renewal from the PKIaaS ACME endpoint. The renewed certificate replaces the expiring certificate in the Kubernetes Secret. Applications that mount the Secret as a volume pick up the new certificate on the next file system sync without a pod restart. Applications that cache the certificate value at startup require a rolling restart, which cert-manager can trigger automatically if configured to do so. The developer does not need to track certificate expiry dates or remember to initiate renewals.

Policy Guardrails via CertificateRequestPolicy

cert-manager’s policy approver adds the enforcement layer that transforms ACME-backed cert-manager from a convenient certificate tool into a governed platform capability. CertificateRequestPolicy resources define what certificate requests are permitted for each namespace or requester. A policy might allow: SANs matching the pattern *.namespace-name.svc.cluster.local, key size of RSA-2048 or ECDSA-256 minimum, certificate validity of 90 days maximum, and Extended Key Usage of TLS Server Authentication and TLS Client Authentication only. Any CertificateRequest that does not match an approved policy is denied before the CSR reaches the PKIaaS CA. The denial is logged, visible to the platform team in the cert-manager audit log, and surfaces in the CLM inventory as a policy violation.

This gives the platform team the guardrail behavior that makes self-service safe: developers can request any certificate that fits within the policy, without approval queue or manual review. Requests that fall outside the policy are automatically denied with an error message that tells the developer which policy constraint they violated and what the correct approach is. The security team defines the policy; the platform enforces it automatically; developers work within it without friction.

CI/CD Pipeline Certificate Issuance

CI/CD pipeline jobs need credentials for a different reason than running services: they need to authenticate to deployment targets, container registries, artifact stores, and the PKIaaS code signing service during the build process. The certificate credential for a CI/CD job should be valid only for the duration of that specific job run, not indefinitely.

OIDC Token Exchange for Pipeline Certificates

Modern CI/CD platforms issue OIDC tokens to pipeline jobs that encode the job’s identity: the repository, the branch, the workflow name, and the environment. These tokens are short-lived and signed by the CI/CD platform’s OIDC provider. The platform team configures the PKIaaS ACME endpoint to accept these OIDC tokens as External Account Binding credentials through a token exchange flow: the pipeline job presents its OIDC token to a configured exchange endpoint, which validates the token against the CI/CD platform’s JWKS endpoint and issues an EAB credential. The pipeline job uses this EAB credential to request a certificate from the PKIaaS ACME endpoint.

The resulting certificate is valid for the configured pipeline certificate profile (typically 1 to 4 hours, covering the maximum expected pipeline runtime). The certificate encodes the pipeline’s identity in its subject (the repository and workflow in the CN or SAN URI field). When the pipeline job uses this certificate to authenticate to deployment targets or signing services, those systems can verify the pipeline’s identity from the certificate and make authorization decisions based on which repository and workflow is running. The certificate expires automatically when the job ends. No secrets rotation is required: there are no long-lived credentials to rotate because no long-lived credentials are issued.

Code Signing Certificates for Pipeline Artifacts

The same PKIaaS CA that issues service certificates and pipeline identity certificates can also issue code signing certificates for signing container images, binaries, packages, and deployment manifests produced by the CI/CD pipeline. The platform team configures a separate code signing certificate profile in the PKIaaS CA (with the Code Signing Extended Key Usage OID 1.3.6.1.5.7.3.3) and exposes it through the PKIaaS REST API or a dedicated signing service. Pipeline jobs that produce artifacts request a signing certificate through this profile, sign their artifacts, and the certificate expires when the job ends. Kubernetes admission controllers (Sigstore’s Policy Controller, OPA/Gatekeeper with image verification policies) can verify container image signatures against the PKIaaS CA trust root before allowing deployment, ensuring that only images signed by authorized pipeline jobs are admitted to the cluster.

Infrastructure-as-Code Integration

Not all workloads in an enterprise IDP run in Kubernetes. Virtual machines, bare metal services, serverless functions, and network appliances all need certificates, and their platform teams often manage infrastructure through Terraform, Pulumi, or Ansible rather than Kubernetes manifests. PKIaaS exposes a REST API that infrastructure-as-code tools can consume directly.

For Terraform-based IDPs, the HashiCorp Vault PKI secrets engine can be configured to use PKIaaS as the upstream CA, exposing a Vault PKI mount that Terraform resources consume through the Vault Terraform provider. The platform team manages the Vault configuration and the PKIaaS CA integration; Terraform modules that application teams write consume the Vault PKI mount without knowing the underlying PKIaaS CA. Certificate issuance happens as part of the Terraform apply: the resource definition specifies the desired certificate parameters, Vault issues the certificate from its PKIaaS-backed PKI mount, and the certificate is stored in Vault’s secret store. Terraform state references the Vault secret path; the actual certificate private key is never written to Terraform state or a version control system.

For Ansible-based provisioning, the PKIaaS REST API can be called directly from Ansible tasks using the uri module, or through community-developed Ansible modules for ACME certificate management. The platform team provides a standardized Ansible role that wraps the PKIaaS certificate issuance API and handles key generation, CSR construction, submission, and certificate storage in a standard path on the provisioned host. Application teams include the role in their playbooks with parameters specifying the desired certificate type (which maps to a PKIaaS certificate profile); the role handles everything else.

Backstage and Service Catalog Integration

Many mature platform teams use a developer portal (Backstage being the most widely adopted open-source option) as the front-end interface to the IDP. For development teams that prefer a UI-driven request flow over writing Kubernetes manifests or Terraform code, the PKIaaS certificate issuance capability can be surfaced in the service catalog as a software template.

A Backstage software template for certificate issuance presents the developer with a form: select the certificate type (from a dropdown of approved templates), enter the service name (which populates the CN and DNS SAN based on the team’s naming policy), select the deployment environment (which determines the issuing CA and the validity period). Submitting the form triggers a scaffolding action that creates the cert-manager Certificate resource (or the Terraform variable file, or the Ansible playbook invocation) in the team’s GitOps repository through a pull request. The developer approves the pull request; the GitOps pipeline deploys the Certificate resource; cert-manager issues the certificate from PKIaaS. The developer’s interaction with PKI amounts to filling out a two-minute form. The platform enforces the security team’s certificate policy in the background.

The Backstage service catalog can also surface certificate health information for services registered in the catalog. A Backstage plugin connected to the CLM layer can display each service’s certificate inventory, current expiry dates, renewal status, and any policy violations in the service’s Backstage entity page. Developers get visibility into their service’s certificate status without leaving the developer portal, and the security team gets the same visibility from the CLM platform’s centralized dashboard without needing to query developers about their certificate posture.

Designing Certificate Templates for Platform Teams

The certificate template design is the most consequential security decision in the platform team’s PKIaaS integration. Templates determine what the platform will issue; policy determines what it will not. A well-designed template set for an enterprise IDP typically includes the following categories:

Internal service TLS certificate. Used for HTTPS endpoints on internal services that do not need to be trusted by external clients. Subject CN: service-name.namespace.svc.cluster.local. SANs: DNS SAN matching the Kubernetes Service DNS name and optionally the pod’s IP address as an IP SAN. Key: ECDSA P-256 or RSA-2048. Validity: 90 days. EKU: TLS Server Authentication. Auto-renewals handled by cert-manager.

mTLS client certificate (service identity). Used by services that make outbound calls to other services requiring mutual TLS authentication. Subject CN: the service’s identity name. URI SAN: SPIFFE ID if SPIFFE is in use. Key: ECDSA P-256. Validity: 24 to 48 hours (short-lived, matched to container lifecycle). EKU: TLS Client Authentication. Auto-renewed by cert-manager or SPIRE.

CI/CD pipeline job certificate. Used by pipeline jobs to authenticate to deployment targets and signing services. Subject CN: the repository and workflow identifier. URI SAN: the pipeline job’s OIDC subject claim. Key: ECDSA P-256. Validity: 1 to 4 hours. EKU: TLS Client Authentication. Issued via OIDC token exchange at pipeline start, expires at pipeline end.

Internet-facing TLS certificate. Used for services that need to be trusted by external clients. Subject CN: the public domain name. SANs: all applicable public domain names. Key: ECDSA P-256 or RSA-2048. Validity: aligned to CA/B Forum SC-081v3 schedule (200 days until March 15, 2026; 100 days until March 15, 2027; 47 days from March 15, 2029). EKU: TLS Server Authentication. Auto-renewed by cert-manager. This template requires either a publicly trusted issuing CA or cross-certification with a public CA root, as private CA certificates are not trusted by public browsers.

Code signing certificate. Used by pipeline jobs to sign container images, binaries, and deployment manifests. Subject CN: the pipeline or team identity. Key: RSA-4096 or ECDSA P-384 (higher assurance than service certs). Validity: 1 to 4 hours. EKU: Code Signing (OID 1.3.6.1.5.7.3.3). Access restricted to authorized signing pipelines by CertificateRequestPolicy.

Audit Visibility and Security Team Integration

Self-service certificate issuance creates an audit trail question: if any developer can request a certificate through the platform, how does the security team know what has been issued and whether the issuance was policy-compliant? The answer is the CLM layer connected to the PKIaaS CA.

Every certificate issuance event through the platform-exposed PKIaaS endpoints is logged in the PKIaaS audit log with the issuing CA, the certificate subject and SANs, the requesting identity (the cert-manager service account, the pipeline OIDC subject, or the Terraform workspace), and the timestamp. The CLM platform connected to the PKIaaS CA provides the security team with a unified view of the entire certificate estate across all platform tenants: which services have certificates, what their expiry profiles look like, which certificates are approaching renewal, and which certificate requests were denied by policy.

For the security team, this is materially better than the alternative (no visibility into developer-issued certificates, relying on network scanning to find what is actually deployed). For the platform team, it provides the evidence base for compliance audits: every certificate in the environment can be traced back to an authenticated issuance request through the platform, rather than being of unknown provenance.

SIEM integration from the CLM platform feeds certificate lifecycle events (issuance, renewal, expiry warnings, policy violations, revocation events) into the security monitoring stack alongside other infrastructure events. An expiry alert for a service certificate appears in the same SIEM dashboard as a failed login attempt or an anomalous network connection, giving the security team contextual visibility into certificate risk without requiring a separate certificate management console.

Multi-Cluster and Multi-Environment Design

Enterprise IDPs typically span multiple Kubernetes clusters (development, staging, production, region-specific clusters) and multiple deployment environments (public cloud, on-premises, edge). The PKIaaS CA hierarchy design must account for this topology.

The recommended design uses a single PKIaaS root CA with environment-specific issuing CAs: a development issuing CA for all development clusters, a staging issuing CA for all staging clusters, and one or more production issuing CAs for production clusters (potentially region-specific issuing CAs for data residency requirements). Each issuing CA has its own certificate profile set appropriate to that environment. The development environment CA may allow longer validity periods and looser naming constraints because certificate expiry in development causes developer friction. The production environment CA enforces shorter validity periods and strict naming constraints because certificate expiry in production causes user-facing incidents.

Environment isolation through the CA hierarchy means a certificate issued by the development issuing CA cannot authenticate to a production service. The production service’s trust store contains only the production issuing CA certificate (not the development one), even though both chain to the same root. This is a technical control on the blast radius of development environment compromises: a compromised development cluster cannot be used to impersonate a production service even if the attacker obtains a development-environment certificate.

47-Day Certificate Validity and Platform Engineering

CA/B Forum Ballot SC-081v3, approved April 2025, establishes the following schedule for maximum TLS certificate validity for publicly trusted certificates: 200 days from March 15, 2026; 100 days from March 15, 2027; 47 days from March 15, 2029. For platform teams managing a large Kubernetes-based certificate estate, this creates an automation mandate: certificates renewing every 47 days cannot be managed manually. The only viable operational model is automated renewal through cert-manager or an equivalent controller.

Platform teams that integrate PKIaaS-backed cert-manager automation into the IDP now are building the 47-day compliance solution as a side effect of solving the immediate developer self-service problem. Every Certificate resource declared in a developer’s Kubernetes manifest is automatically managed by cert-manager, which renews it before expiry regardless of the validity period. A transition from 90-day to 47-day certificates requires only a change to the certificate profile’s validity period in the PKIaaS CA and CertificateRequestPolicy configuration. The developer-facing interface (the Certificate resource declaration in the Helm chart) does not change. The compliance transition is a platform configuration change, not a developer migration project.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA backend for IDP certificate issuance: ACME+EAB for cert-manager ClusterIssuer configuration, REST API for Terraform and Ansible integration, OIDC token exchange support for CI/CD pipeline certificate issuance, certificate profiles for each workload category (service TLS, mTLS client identity, pipeline jobs, code signing), and environment-specific issuing CAs for multi-cluster IDP topologies. Contact us at Encryption Consulting to discuss your IDP certificate architecture.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM visibility layer for the platform team and the security team: unified certificate inventory across all clusters and environments, cert-manager Certificate resource discovery, expiry monitoring with configurable alerting thresholds, policy compliance reporting (flagging certificates that violate the platform’s stated template constraints), and SIEM integration for certificate lifecycle event feeds. Backstage plugins that surface CertSecure Manager data in the developer portal enable per-service certificate health visibility without leaving the developer portal.
• CodeSign Secure: For platform teams exposing code signing as an IDP capability, Encryption Consulting’s CodeSign Secure provides the HSM-backed code signing infrastructure that CI/CD pipelines use to sign container images, binaries, and deployment manifests. Signing keys are stored in FIPS 140-3 Level 3 HSMs; every signing event is logged in the audit trail; signing policies restrict which pipelines can sign which artifact types. Integration with Kubernetes admission controllers (Sigstore Policy Controller) enables signature verification as an admission gate on all cluster deployments.
• PKI Services: For platform teams designing the PKIaaS IDP integration from scratch, Encryption Consulting’s PKI Services provide CA hierarchy design for multi-cluster and multi-environment IDPs, certificate template design for each workload category, cert-manager CertificateRequestPolicy configuration, OIDC token exchange setup for CI/CD pipelines, Terraform and Ansible integration patterns, and Backstage plugin advisory for certificate health surface in the developer portal.
• PQC Advisory Services: Platform teams that build PKIaaS-backed certificate automation into the IDP now are also laying the foundation for the post-quantum certificate transition. Encryption Consulting’s PQC Advisory Services integrate ML-DSA (FIPS 204) hybrid certificate issuance planning into the IDP certificate template design, so the PQC transition is a configuration change to the PKIaaS profiles and cert-manager templates rather than a developer-facing migration project.

Conclusion

The internal developer platform is the right place to solve the enterprise certificate management problem for developer workloads. Developers need certificates; they should be able to get them through the same tooling they use for everything else in the platform. Security teams need visibility and policy enforcement; they should get it automatically from the platform’s CLM layer, not through manual review of individual requests. Platform teams need a scalable, maintainable solution; they should get it from a properly integrated PKIaaS backend rather than from a collection of scripts and shared secrets.

The integration is not complex. cert-manager ClusterIssuer pointing at a PKIaaS ACME endpoint. CertificateRequestPolicy defining the guardrails. OIDC token exchange for pipeline jobs. Vault PKI secrets engine for Terraform consumers. A Backstage template for teams that want a UI. These are all standard platform engineering patterns, and PKIaaS is the governed CA backend that makes them work without creating a security debt that accumulates faster than the platform team can pay it down.

The CA/B Forum 47-day certificate validity schedule makes this integration urgent. Platform teams that automate certificate issuance and renewal before 2029 are building a platform capability that will handle the compliance transition without a developer-facing migration. Platform teams that wait are building a manual process that will fail at the 47-day scale.

If your platform team is designing PKIaaS integration for your IDP and wants to validate the architecture, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when cert-manager, Backstage, the CA/B Forum SC-081v3 validity schedule, or major IDP platforms publish updates that affect certificate automation integration patterns.

Frequently Asked Questions

What is the role of PKIaaS in an Internal Developer Platform?

PKIaaS is the governed CA backend that the platform team configures once and exposes through standard IDP interfaces: cert-manager ClusterIssuers for Kubernetes workloads, ACME endpoints with OIDC authentication for CI/CD pipeline jobs, Terraform providers for IaC consumers, and Backstage templates for UI-driven requests. Developers get self-service certificate issuance through familiar tooling; the platform enforces the security team’s certificate policy automatically in the background.

How does cert-manager integrate PKIaaS into a Kubernetes-based IDP?

The platform team installs cert-manager and configures a ClusterIssuer pointing at the PKIaaS ACME endpoint with External Account Binding credentials. Developers declare Certificate resources in their Kubernetes manifests; cert-manager handles issuance, stores the certificate as a Kubernetes Secret, and renews it automatically before expiry. cert-manager’s CertificateRequestPolicy enforces the platform’s certificate profile guardrails, rejecting requests that fall outside approved parameters before the CSR reaches the PKIaaS CA.

What are certificate request templates in the context of PKIaaS and IDPs?

Certificate request templates are pre-configured, policy-approved specifications for each workload category: allowed SAN patterns, validity periods, key algorithms, and EKU OIDs. Developers select a template when requesting a certificate; the platform enforces the template’s constraints without the developer needing to understand certificate policy details. Templates map to certificate profiles in the PKIaaS CA and to CertificateRequestPolicy resources in cert-manager.

How should a platform team handle certificate requests for non-Kubernetes workloads?

For VMs and bare metal: ACME clients (certbot, acme.sh) pointed at the PKIaaS ACME endpoint. For Terraform: HashiCorp Vault PKI secrets engine with PKIaaS as the upstream CA, consumed through the Vault Terraform provider. For Ansible: the PKIaaS REST API called from Ansible tasks, wrapped in a standardized platform role. For network appliances: EST or SCEP endpoints. For CI/CD pipeline jobs: OIDC token exchange issuing short-lived pipeline certificates without pre-shared secrets.

What guardrails should platform teams build into certificate issuance for developer self-service?

Five guardrail categories: subject naming constraints (allowed CN and SAN patterns per namespace/team, enforced by CertificateRequestPolicy), validity period limits (maximum validity per workload type), key algorithm minimums (minimum key size and algorithm requirements), certificate type restrictions (each team/namespace can only request types appropriate to their workload, no CA or code signing certificates through the general developer interface), and audit visibility (all issuance events logged to PKIaaS audit log and surfaced in CLM platform).