Scoping a PKI Requirement: What to Include Before You Approach the Market
The quality of a PKI engagement is very often decided before a single supplier is contacted. It is decided in the requirement, the document that tells the market what the organisation needs. A well-formed requirement attracts accurate, comparable proposals and sets a project up to run to plan. A vague or incomplete one attracts caveated bids, invites scope disputes later, and quietly inflates both cost and delivery risk.
PKI is particularly unforgiving here, because it touches so much of the technical estate and so many parts of the organisation. A requirement that captures only the obvious elements leaves the difficult questions to be discovered mid-project, which is the most expensive place to discover them. This article sets out what a well-scoped PKI requirement contains, and the gaps that most commonly undermine one.
Why scoping is where cost and risk are set
Suppliers price what they can see. Where a requirement is clear, they can quote accurately and commit with confidence. Where it is ambiguous, they do one of two things, both of which work against the buyer. They either price in contingency to cover the unknowns, inflating the cost, or they price optimistically and recover the difference later through change requests once the true scope emerges. Either way, the gap in the specification becomes a cost the organisation pays, and often a delay it absorbs as well.
Poorly scoped requirements also make proposals difficult to compare. When each supplier has made different assumptions to fill the same gaps, the buyer is no longer comparing like with like, and the evaluation becomes a guess. Time spent getting the requirement right is repaid several times over in cleaner proposals, firmer prices and fewer surprises in delivery.
What a well-scoped PKI requirement includes
A thorough requirement addresses the technical, operational and governance dimensions of the PKI, not just the technology. The areas below are the ones that matter most.
Purpose and use cases
The requirement should state clearly what the PKI is for. The use cases, whether TLS, mutual TLS, user authentication, smartcards, code signing, document signing, device identity or others, shape almost every downstream decision. So too do the applications and services that will depend on the PKI, both now and in the near pipeline. A specification that lists the technology without anchoring it to concrete use cases invites a solution that is technically sound but poorly matched to what the organisation actually needs.
Scale, growth and availability
Suppliers need to understand the size of the estate and its expected trajectory: the number of certificates and subscribers today, and the growth anticipated over the life of the solution. They also need the availability and resilience requirements, including business continuity, disaster recovery, and any recovery time and recovery point expectations. These figures drive architecture and cost directly, and their absence is a frequent cause of solutions that fit today but not tomorrow.
Infrastructure, integration and identity
A PKI does not exist in isolation. The requirement should describe the core infrastructure model, whether on-premise, cloud or hybrid, the virtualisation platform, and the network architecture the PKI must integrate with or traverse. It should also identify the identity provider, the authentication methods to be supported, the endpoint types to be managed, and any monitoring and audit systems the PKI is expected to feed. Integration is where PKI projects most often meet unexpected complexity, so naming these dependencies up front is one of the highest-value things a requirement can do.
Certificate policy, profiles and governance
The requirement should address the governing framework: whether a Certificate Policy and Certification Practice Statement already exist or need to be produced, the certificate profiles and templates required, and the naming standards and any naming constraints. It should also capture the regulatory and compliance drivers that apply, such as eIDAS, PCI DSS or sector-specific obligations, because these shape the controls the solution must satisfy.
Key protection and hardware security modules
Where hardware security modules are involved, the requirement should set out the expectations around key protection: any HSM vendor or form factor preferences, backup and recovery requirements, local or remote management needs, and any duty separation, multi-person or quorum controls. For offline or constrained environments, form factor matters, and stating it early avoids a costly redesign later.
Service, support and operating model
Finally, the requirement should describe how the PKI will be run once it is live: who will operate and maintain it, the support window required, and any incident, change and security management procedures the solution must align to. A specification that stops at the build and says nothing about operation leaves one of the most consequential questions unanswered.
The gaps that most often cause problems
Certain omissions recur, and each has a predictable effect on cost and delivery risk.
The most common is existing estate and migration. Where a PKI already exists, the requirement must say so, and describe the current hierarchy, the technology in use, and whether the new solution is a replacement or must co-exist with the old. It should state whether migration is required, and whether it is a hard cut-over or a soft transition with a dual-trust period. Migration is one of the most complex and risk-laden aspects of any PKI project, and a requirement that omits it almost guarantees a disruptive discovery later. Our experience of these projects is reflected in our work on migration de-risking.
The second is revocation and monitoring. Requirements frequently specify how certificates will be issued but say little about how revocation will be published and checked, or how the certificate authorities, revocation endpoints and certificate lifetimes will be monitored. These are precisely the areas whose failure causes outages, so leaving them unstated pushes real operational risk into delivery.
The third is the operating model, noted above. A requirement that scopes the build but not the run leads to a solution that is delivered and then orphaned, with no clear answer to who keeps it healthy.
The fourth is key ceremony and assurance requirements. Where a formal key signing ceremony is needed, the requirement should state the standards it must meet, the witness and audit expectations, and any pre-approval requirements. These carry long lead times and specific logistics, and discovering them late can delay a project by weeks.
Each of these gaps has the same underlying effect. It transfers a decision from the requirement, where it can be considered calmly and priced accurately, into the project, where it must be resolved under time pressure and usually at additional cost.
Getting the requirement right before you go to market
The most reliable way to produce a well-scoped requirement is to establish a clear, independent picture of the current estate and the target outcome before writing it. For organisations with an existing PKI, that often means a structured assessment of what is in place, so that the requirement is grounded in reality rather than assumption. A PKI Health Check provides exactly that baseline, and for organisations building from scratch, early PKI consultancy can help translate business objectives into a requirement the market can respond to accurately.
How Unsung helps
Unsung is a UK-based, specialist PKI consultancy with a team of more than 20 dedicated PKI experts serving government, defence, financial services, healthcare, transport and critical national infrastructure clients. We work on a strictly vendor-neutral basis, which means the advice we give on scoping a requirement is shaped by what is right for the organisation, not by any product we might later propose.
For organisations preparing to go to market, we help define requirements that attract accurate, comparable proposals and set projects up to run to plan, drawing on deep experience of PKI design, build, migration and operation. If you are scoping a PKI requirement and would value independent input before you approach the market, contact us to discuss how we can help.
