A two-page version of this page is the printable service sheet: https://securepeak.com/datasheets/edge-infrastructure/
The objective
Connect infrastructure decisions to measurable service behaviour.
For infrastructure teams operating security-sensitive services.
A routing, certificate or service dependency change carries risk that is hard to see in advance.
- Architecture review
- Understand dependencies, trust boundaries and ownership.
- Operational verification
- Define measurement coverage and exercise the recovery process. These require separate evidence.
Questions this work helps answer
- Which dependencies does a critical service actually rely on?
- Where do identity and certificate services sit on the request path?
- What would be measured to show that a change worked?
- Who owns recovery when a dependency fails?
Method
How the work is approached
Model the dependencies
Transport, trust services and application dependencies are mapped with their owners.
Review design and operation separately
Architecture review and operational measurement answer different questions and need different evidence.
Plan for recovery
Runbooks and owners are checked against the failure modes the model identifies.
Scope
What an engagement can include
Each engagement is scoped to your system and objectives. These are the areas it can draw on.
- Trust services on the request path
- Revocation (OCSP and CRLs), trust-anchor distribution, Certificate Transparency monitoring, timestamping and secure resolution: services that sit inline in a handshake or lookup, where a late answer fails like a wrong one.
- Routing and dependencies
- BGP and RPKI route-origin validation, anycast and failover design, and the third-party providers each critical service depends on.
- Change and recovery
- Dependency mapping before a change, rollback criteria and recovery runbooks exercised with the owners who will use them.
- Measurement design
- What to measure to show that a change worked, where to measure it from, and how the limits of that coverage are stated.
Not included
- General-purpose content delivery or web hosting
- Last-mile connectivity
- Hosting origin infrastructure
Each of these needs its own scope and authorisation.
Reference frameworks
Public frameworks an engagement can map its findings and deliverables to.
Key termsOCSP staplingCRLCertificate TransparencyBGPRPKIAnycast
Practical outputs
What you receive
Deliverables are agreed for your system and the objectives of the engagement.
Service and dependency inventory
Availability and latency measurement plan
Operational and recovery runbooks
Illustrative deliverable
A dependency record
A synthetic example of how the work can be structured. The actual content is agreed for your engagement.
- Service
- A bounded application workflow
- Depends on
- Transport, identity and certificate services
- Review
- Architecture and ownership
- Validation
- Measurement and recovery require separate evidence
From scope to handover
How the engagement works
Requirements and inventory
Map services, dependencies, operating requirements and measurement coverage.
Architecture and deployment
Review the architecture and agreed deployment approach.
Measurement and operations
Validate measurements and hand over operational and recovery runbooks.
Inputs
What we can start from
None of these is required in full. Conclusions are limited to the evidence that is available, and the report says so.
- Network and service architecture documentation
- Certificate and identity service dependencies
- Existing monitoring and measurement arrangements
- Planned changes, deployments or migrations
Common questions
Before you get in touch
Do you operate infrastructure for us?
The engagement reviews, plans and validates. Operational responsibility stays with your teams unless something else is agreed.
Can you measure performance?
Measurement needs agreed coverage and infrastructure. An architecture review does not by itself establish measured performance.
What do we receive?
Service and dependency inventory; availability and latency measurement plan; and operational and recovery runbooks, in formats agreed during scoping.
Optional
Prepare for a first call
Note the decision, the systems and what you already have. The page turns it into a short plain-text brief you can bring to the call.
Start with your system
A clear scope comes first.
Tell us what you are working on and what needs to change. We agree who leads the work, the timeline, acceptance criteria and reporting schedule before work starts.
Every engagement is scoped and led by one of SecurePeak's engagement leads, named before work starts. Meet the engagement leads.
Useful starting points
- Services and operational dependencies
- Routing and certificate infrastructure
- Measurement and recovery objectives
Explore this work
Which dependency matters when the system changes or fails?