From Discovery to Go-Live: How a PKI Design and Build Engagement Runs
Building a Public Key Infrastructure from the ground up is one of the more consequential projects an organisation can undertake. The infrastructure that results will underpin the trust behind certificates, authentication and encryption across the estate for years, and decisions taken early are expensive to unpick later. Yet for many organisations approaching a build for the first time, the process itself is opaque. What actually happens between signing a statement of work and handing a working service to the operations team?
This article sets out how Unsung runs a PKI design and build engagement, phase by phase. It also draws attention to the points where organisations most often underestimate the effort involved, because knowing where projects lose time is the surest way to avoid losing it.
The shape of the engagement
A well-run PKI build moves through a defined sequence: discovery and planning, design, build, configuration, testing, and handover into live service. Each phase has clear entry and exit criteria, its own deliverables, and a formal review before the project proceeds. Running alongside all of it is a continuous thread of project governance, keeping stakeholders informed and risks under control from the first week to the last.
The discipline matters. PKI is unforgiving of shortcuts, and a build that skips ahead to install kit before the design is settled tends to pay for it later in rework. The structure below is what keeps a complex project predictable.
Phase one: discovery, requirements and planning
Every engagement begins by understanding the ground it is being built on. Discovery and due diligence establish the client's governance landscape, the key stakeholders, the people who approve each deliverable, and the delivery environment in both its technical and cultural dimensions. This last point is easy to overlook and frequently decisive: a technically sound plan can still stall against an approval process nobody mapped at the outset.
From discovery, the requirements are captured and baselined. A Statement of Requirements is agreed as the approved reference point for the build, and where the engagement calls for it, a Requirements Traceability Matrix links each requirement through to the outcomes and capabilities that will satisfy it. That traceability becomes the backbone of testing later, because every test written can be tied back to a requirement it proves.
Planning then turns requirements into a structured delivery plan with timelines, dependencies and milestones, supported by a RAID log capturing risks, actions, issues and dependencies from day one, and a communications plan that sets the cadence of governance meetings and stakeholder updates.
Where organisations underestimate effort: discovery is routinely treated as a formality and compressed. In practice, the time taken to identify the right approvers and understand the client's internal governance is the single most common determinant of whether the later phases run to schedule. Approvals that surface late, from a design authority nobody flagged or a security function brought in after the design is drafted, are among the most frequent causes of slippage.
Phase two: design
With requirements agreed, the design phase produces the High-Level Design covering the technical, administrative, operational and business-change aspects of the solution. This is where the trust hierarchy, the certificate authorities, and the operational model take shape. Design decisions are documented with their rationale in a decisions log, so the reasoning behind the architecture is preserved rather than lost to memory.
Where the engagement requires it, the design extends to a Low-Level Design or configuration document capturing the detailed build settings, a Bill of Materials listing the infrastructure, software and components to be procured, and the Certificate Policy and Certificate Practice Statement that govern how the PKI will be operated and trusted. If the client already holds a design, Unsung can instead provide quality assurance against it rather than starting afresh.
The phase closes with a Build Readiness Review, a formal confirmation that the components, documentation, dependencies and assumptions are validated and complete before any build begins.
Where organisations underestimate effort: two areas consistently take longer than expected. The first is the Certificate Policy and Certificate Practice Statement, which require input from stakeholders beyond the technical team and often several rounds of review. The second is procurement lead times against the Bill of Materials. Hardware security modules and appliances can carry long delivery windows, and a build cannot begin until the kit arrives. Both are best started early rather than treated as design-phase afterthoughts.
Phase three: build
The build phase prepares the environment the PKI will run on. For on-premise deployments, this means validating shipped items against the Bill of Materials, racking and connecting hardware to power and network, capturing serial numbers for the configuration management database, initialising the hardware and patching it to current firmware. For cloud deployments, it means validating the specified resources, access and integrations. Where hardware security modules are involved, tamper-evident packaging information is recorded on unboxing, an audit step that matters for later assurance.
Base platform components are then installed and patched, with software assets configured to a basic level and hardware assets recorded and tagged. This is deliberately foundation work; the full, client-specific configuration comes next.
Where organisations underestimate effort: environment readiness is frequently the hidden dependency. Network configuration, firewall rules, access provisioning and data-centre logistics sit with the client's own teams, and a build team ready to work can be held up waiting on them. The physical or cloud environment being genuinely ready, not nominally ready, is worth confirming before the build window opens.
Phase four: configuration
Configuration is where the PKI takes its intended form. All design-specified configuration items are implemented, the certificate authorities, registration and validation authorities, hardware security modules and access controls, exactly as set out in the design. Alongside the core PKI, the operational management layer is configured: the connectors, integrations, system access, reporting, monitoring, auditing, alerting and dashboards that make the service manageable in life.
Where the build calls for it, a Key Signing Ceremony is conducted to bring the root of trust into being under controlled, witnessed conditions. Configuration documentation is maintained throughout and updated to reflect the final state, and a Test Plan is prepared defining the scope, roles, tooling, defect categorisation and exit criteria for the testing phase to come.
Phase five: testing
Testing proves that what was built satisfies what was agreed. It opens with a Testing Readiness Review confirming that components, documentation, dependencies and testing inputs are validated and complete. Test scripts, written against the baselined requirements so that each traces back to something it proves, are then executed across functional and non-functional requirements, covering user acceptance, integration, security and operational acceptance testing, with the actual outcome of each test recorded.
Defects are captured in a defect tracker, categorised, prioritised and assigned for resolution, with configuration documentation updated as fixes are applied. A Test Report documents the cycle, the defects, the fixes and confirmation that the exit criteria have been met. A Service Acceptance Checklist then validates that service-related artefacts are complete, defects are resolved, and project risks have been transposed into the operational risk register.
Where organisations underestimate effort: testing is where accumulated shortcuts come due. Requirements that were left ambiguous in phase one become disputes over whether a test has passed. Defects found late, particularly in integration with surrounding systems, can require configuration rework that ripples back through documentation. Disciplined requirements and traceability earlier in the engagement are what keep this phase from expanding.
Phase six: handover, warranty and closure
The final phase transitions the solution from a project into a service the organisation can run. A Service Acceptance Review, run against the checklist, confirms the service is ready to be consumed by the business, and an Operational Readiness Review confirms the operational teams and tooling are in a position to run it. Runbooks and playbooks equip those teams to manage the solution, supported where required by operational training delivered in person or as recorded sessions.
Outstanding RAID items are formally handed over to the client, moving from the project register to the operational one, and a warranty period and support structure are agreed with defined escalation paths. A Project Closure Presentation sets out what was asked, what was delivered, what remains open, and where residual risks and actions now sit. Formal BAU acceptance sign-off marks the point at which the service is the organisation's own.
Where organisations underestimate effort: operational readiness is often assumed rather than verified. A technically complete PKI still needs a prepared team, working runbooks and clear escalation routes before it can be considered live. Treating handover as a genuine phase, rather than a final formality, is what prevents a successful build from faltering in its first weeks of operation.
The thread that runs throughout: governance
Underneath every phase sits continuous project management. Weekly project and RAID review sessions with the client keep status and risk visible, a weekly progress report issued to all stakeholders tracks delivery against the plan with a clear RAG position, and an actions tracker and decisions log maintain a defensible record of what was agreed and why. This governance is not overhead; it is what allows a complex, multi-phase build to remain predictable and gives the client confidence at every milestone.
How Unsung approaches design and build
Unsung is a UK-based specialist PKI consultancy with a team of more than 20 dedicated PKI experts. Our PKI Design and Build service applies this structured, phase-gated methodology to greenfield builds and major platform deployments alike, always on a vendor-neutral basis, so the architecture is shaped by the client's requirements rather than a product preference. The Greenfield PKI Design and Discovery case study shows the approach applied in practice.
For organisations building a PKI for the first time, the value of a structured engagement is that it removes the guesswork. Each phase has a defined purpose, a clear deliverable and a formal gate, and the points where projects usually lose time are anticipated rather than discovered. If a PKI build is on your horizon and you would like to understand how the engagement would map onto your environment and governance, contact us to start the conversation.
