Greenfield PKI Design & Discovery

The engagement

Unsung contracted with a major public sector organisation to design and deliver a highly available PKI platform for a new private cloud environment. The PKI service was required to satisfy stringent security and assurance requirements whilst simultaneously supporting modern DevOps workflows, CI/CD pipelines, autoscaling compute infrastructure, and enabling delegated certificate management to product teams.

This engagement represented a significant modernisation initiative, moving from traditional manual PKI operations towards automated certificate lifecycle management aligned with cloud-native architecture principles.

Why the organisation needed a new approach to PKI

Public key infrastructure built for a static, long-lived estate behaves very differently to public key infrastructure built for cloud. In a traditional environment, certificates are issued to known servers with predictable lifespans, requests arrive at a manageable rate, and a small operations team can process them by hand. In a private cloud environment supporting autoscaling workloads and continuous delivery, none of those assumptions hold. Workloads are ephemeral, certificate volumes rise substantially, and demand arrives at the pace of the deployment pipeline rather than the pace of a change advisory board.

The organisation recognised that extending existing manual practices into the new platform would create a bottleneck at precisely the point where the platform was intended to accelerate delivery. Equally, it recognised that a greenfield build represented a rare opportunity: the chance to establish a trust architecture that was correct from first principles, rather than inheriting the accumulated technical debt, undocumented decisions and legacy trust relationships that characterise most established PKI estates.

What was at stake

Where a certificate service cannot keep pace with the platform it supports, one of two outcomes usually follows. Either the PKI becomes the constraint on cloud adoption, with delivery teams waiting on manual issuance, or delivery teams route around it entirely, using self-signed certificates, unmanaged local certificate authorities and ad hoc trust stores. The second outcome is the more damaging, because it erodes assurance quietly and is rarely visible until something fails or an audit exposes it.

The organisation also operated under assurance and governance obligations that required design decisions to be evidenced and defensible. It was not sufficient for the platform to be secure; it had to be demonstrably secure, with documented policy, recorded design rationale, and evidence that the service performed as designed before it entered live operation.

How Unsung was engaged

Unsung was engaged as a vendor-neutral delivery partner, accountable from initial discovery through to acceptance into business-as-usual operation. That end-to-end scope mattered: it meant a single team held the thread from requirement to running service, so design intent was not lost in handovers between advisory, integration and operations suppliers. Our role combined architectural authority with practical delivery, working alongside the organisation's platform, security, assurance and product teams throughout.

Unsung delivered a comprehensive, highly available PKI platform with extensive automation capabilities. The engagement followed Unsung's structured design and build framework, which sequences work through discovery, design, build, configuration, testing and handover, with formal review gates between each phase.

Discovery and requirements

The engagement opened with a discovery and due diligence exercise covering the existing certificate estate, the intended target architecture, the assurance obligations the service would need to satisfy, and the working practices of the product teams who would become its principal consumers. This is deliberately broad: certificate requirements are rarely articulated fully at the outset, because the teams who depend on certificates often think in terms of applications and pipelines rather than trust hierarchies.

Findings were consolidated into an approved Statement of Requirements, supported by a requirements traceability matrix linking each requirement through to the capability that would satisfy it and the outcome it supported. Traceability of this kind pays for itself later in the engagement, because it allows scope questions and design trade-offs to be resolved against agreed requirements rather than against opinion. Project governance was established in parallel, including a delivery plan with sequenced milestones and dependencies, a communications plan, a RAID log and a formal project kickoff.

Design

Design work produced a High-Level Design covering not only the technical architecture but the administrative, operational and business change dimensions of the service. Establishing a certificate authority is a modest technical undertaking by comparison with establishing the operating model around it, and designs that address only the technology tend to produce platforms that work but cannot be run. The High-Level Design was supported by low-level configuration detail, a bill of materials for the infrastructure and software components required, and a decisions log recording the rationale behind each significant architectural choice.

Governance documentation was developed alongside the technical design rather than retrofitted after it, which keeps policy and implementation aligned. Governance deliverables included:

• Certificate Practice Statement
• Key Signing Ceremony documentation, facilitation, and execution

The design phase concluded with a Build Readiness Review, providing a formal checkpoint that design was sufficiently mature, dependencies were understood and the environment was ready to receive the build.

Build and configuration

Build activity prepared the cloud environment, installed and hardened the base platform components, and established patching and asset management arrangements from the outset rather than as a later remediation. Configuration then delivered the certificate authority, registration authority, validation authority, timestamping and code signing services across two geographically separated sites, together with the operational management layer: system integrations and connectors, access control, monitoring, auditing, alerting, reporting and dashboards.

That operational management layer is frequently underestimated. A certificate service that issues correctly but cannot be observed, audited or alerted upon is a service that will eventually fail without warning. Configuration documentation was maintained as a living record throughout, so that the documentation handed to the operations team described the platform as actually built.

Testing and assurance

A test plan was agreed defining scope, dates, roles and responsibilities, tooling, defect categorisation and the exit criteria for the testing phase. Testing was executed against documented test scripts, with defects categorised, prioritised and tracked to resolution, and results consolidated into a test report. A service acceptance checklist provided the objective basis for the decision to proceed. Technical deliverables across the engagement included:

• Statement of Requirements
• Technical Design (High-Level Design, Low-Level Design)
• Testing collateral (Test Plan, Test Scripts, Test Report)
• CA, RA, VA, Timestamping, and Code Signing services across two geographically separated sites
• Automated certificate issuance and renewal workflows

Handover and operational readiness

Handover was treated as a phase in its own right. Runbooks and playbooks were produced for the teams who would operate the service, operational training was delivered, and formal operational readiness and service acceptance reviews were held before business-as-usual acceptance signoff. Outstanding risks, actions, issues and dependencies were transitioned to the client through a structured RAID handover, with a defined warranty period and agreed escalation paths supporting the transition into live service.

The engagement presented significant infrastructure dependency and organisational change challenges.

Delivering into an environment that was still being built

The PKI platform was being delivered into a nascent private cloud hosting environment where many technical dependencies were either not yet in place or at varying stages of maturity. Unsung successfully managed these dependencies through close collaboration with customer platform delivery teams.

In practice this meant sequencing the engagement so that design and documentation work progressed while underlying platform capabilities matured, holding dependencies visibly in the RAID log with named owners rather than allowing them to sit as informal assumptions, and recording design decisions taken on the basis of expected platform behaviour so that they could be revisited efficiently if that behaviour changed. Working this way avoids the two common failure modes in dependent delivery: stalling until every dependency is resolved, or building on assumptions that are never re-examined.

Introducing automation to an organisation that had not operated it before

The engagement represented the first introduction of automated certificate lifecycle management capabilities to the organisation, requiring Unsung consultants to work extensively with assurance and governance stakeholders.

The concern raised by assurance functions encountering automation for the first time is a reasonable one: if certificates are issued without a human approving each request, where has the control gone? The answer is that control moves earlier, into the design of certificate profiles, templates, enrolment policy and the authentication of requesting systems, and into the audit and monitoring that evidences correct operation. Unsung invested significant consultancy effort in making that shift explicit, demonstrating how the automated model produced stronger and more consistently applied control than the manual process it replaced, and evidencing it in terms the organisation's governance framework recognised.

Enabling delegated management without diluting assurance

Delegating certificate management to product teams was a core requirement, and it introduced a tension familiar to any organisation modernising its trust services: the teams closest to the workload should be able to obtain certificates without friction, but the organisation as a whole must retain oversight of what has been issued, to whom and under what policy. This was resolved through the design of the registration and enrolment model, so that delegation operated within boundaries defined centrally, with central visibility maintained throughout.

Sustaining the platform beyond go-live

A greenfield platform is at its best on the day it is accepted, and the challenge from that point is preventing drift as the estate grows and the original delivery team disperses. Runbooks, documented decisions and an operating model defined during design rather than after it are what allow the organisation to sustain the service on its own terms. Building that capability into the engagement was as much a part of the outcome as the platform itself.