What we do
Crypto-agility, in the network you actually operate
Crypto-agility is the ability to change a cryptographic algorithm without rebuilding the system that depends on it.
In a mobile network that means something specific: certificates and key exchange on the interfaces between disaggregated RAN components; IPsec and TLS on transport and on the service-based interfaces of the 5G core; subscriber identity protection; the roots of trust in equipment that will still be in the field in 2035.
Three pieces of work, in order.
Cryptographic discovery and a telecom CBOM
We build an inventory of the cryptography in use — algorithms, key sizes, certificates, protocol versions, and the components that depend on them — from configuration, from signalling, and from the equipment itself.
The output is a Cryptography Bill of Materials. The CycloneDX CBOM format gives the structure; the value we add is telecom context. A CBOM that lists “TLS 1.2, RSA-2048” is an observation. A CBOM that says which interface, under whose control, bound to which hardware lifecycle, and therefore when it can realistically change, is a plan.
You get: a machine-readable CBOM, a mapped dependency view of what you control versus what a supplier controls, and a written statement of the assumptions and blind spots — including what we could not see and why.
Transition assessment and costing
Not everything migrates on the same clock, and treating it as if it does is how migration programmes lose credibility in their second year.
We separate the estate into what can move under your own change control, what is gated by a vendor's post-quantum roadmap, and what is gated by hardware replacement. Against the NCSC milestones we mark what is genuinely at risk of missing 2031, and what is comfortable. Where an algorithm change carries a performance cost — larger keys and signatures affect handshake latency, packet sizes and signalling volume — we say so with numbers rather than with adjectives.
You get: a prioritised migration sequence tied to the published deadlines, the supplier questions you need answered and when you need them answered, and a costed view that distinguishes engineering effort from procurement.
Measurement-based validation
A migration is finished when it can be demonstrated. We define what to measure before the change, measure the same things after, and report the difference — connection setup times, handshake overhead, failure modes under load, and whether the intended algorithm is in fact the one negotiated on the wire.
You get: a repeatable test definition you keep, before-and-after measurements, and a validation record written so that someone outside the project can follow it.
How we work
Evidence over assertion
Every finding is traceable to something observed. Where we infer, we label it as inference. Where we do not know, the report says we do not know.
Where automation helps
Reading cryptographic configuration across thousands of network elements is a parsing and classification problem at a scale that rewards automation, and we use machine learning for that first pass. Nothing reaches a report on that basis alone: classifications are verified against the source before they are stated as fact.
Standards, not a proprietary framework
We work to the NCSC timeline, GSMA PQ.03, the relevant 3GPP security specifications, O‑RAN WG11's security requirements and protocol specifications, and the NIST standards. Our deliverables are meant to be legible to your auditors and your suppliers, not only to us.
Single operator, single accountability. Thames Smart Tech is a small specialist practice. You deal with the person doing the work.