Fintech platform with a microservices backend
A payments company enforcing mTLS between every internal service, so a compromised container can't silently call the payments service just because it's on the same network.
mTLS & Zero Trust Security for UK Teams
DevOps services · United Kingdom
mTLS and zero trust for UK teams whose architecture has grown past the point where being inside the network is a meaningful security boundary. We set up mutual TLS between your services with an internal certificate authority, short-lived certificates that rotate automatically, and no implicit trust just because a request came from inside the LAN. Included DevOps hours cover certificate rotation and mesh changes ongoing.
- Every service authenticates every other service
- Short-lived certificates, rotated automatically
- No implicit trust inside the network
- VPS 1–8 h/month; dedicated 5–10 h/month depending on plan; GPU 10 h/monthIncluded hours
- Frankfurt, in the EUData centre
- Internal CA (cert-manager / step-ca), managed for youCertificate authority
- EUR invoicing, 20% UK VAT itemisedBilling
01
What zero trust actually changes
Zero trust means a service doesn't get to talk to another service just because it's on the same private network — it has to prove its identity every time, with a short-lived certificate that expires whether or not anyone remembers to revoke it. We set up an internal certificate authority, issue workload identities per service, and configure mutual TLS so every connection is authenticated in both directions, not just encrypted.
- Internal CA issuing short-lived certificates per workload
- Mutual TLS enforced between services, not just at the edge
- Automated certificate rotation, no manual renewal step
- Least-privilege access rules per service identity
02
Best practices we apply
Zero trust fails quietly when the mechanics are half-done — a certificate authority nobody rotates, a service mesh installed but not enforcing policy. We apply the full checklist on every deployment, so the architecture actually delivers the security property it's named after, not just the diagram of it. We document which services trust which, so a new engineer can read the policy instead of reverse-engineering it from the mesh config.
- No implicit trust granted just for being inside the network
- Identity issued and verified per workload, not per network segment
- Least-privilege access rules, reviewed as services are added
- Automated certificate rotation, tested to confirm it actually fires
- Secrets encrypted in git (SOPS) or held in a dedicated vault
03
Service mesh, or sidecar-less mTLS
A full service mesh like Linkerd or Istio gives you mTLS, traffic policy and observability in one layer, at the cost of running a sidecar proxy next to every service. For smaller deployments we often set up mTLS directly — library-level or via a lighter proxy — without the mesh's operational overhead. We'll recommend based on your service count and existing Kubernetes maturity, not a default answer.
04
How the included hours work
DevOps hours come with the plan: 1–8 hours a month on VPS tiers, 5–10 hours a month on dedicated servers depending on the plan, 10 hours a month on GPU servers. Use them for the initial CA and mTLS set-up, onboarding a new service into the trust model, or investigating a certificate rotation failure. Request the work from the client panel under DevOps Services. Hours don't roll over, so most teams build the trust model in one month and onboard services incrementally afterwards.
How we work
Request the work from the panel
You describe your current service architecture and which connections currently rely on network location for trust.
We scope the CA and identity model
We design the internal certificate authority, the per-service identity scheme, and whether a full service mesh is justified.
We deploy and verify rotation
We issue certificates, enforce mutual TLS between services, and deliberately test certificate rotation before calling it live.
We hand over the trust model documentation
You receive the CA structure, the access rules per service identity, and the procedure for onboarding a new service.
Use cases
Healthcare-adjacent SaaS with multiple integrations
A health-tech platform issuing workload identities per integration partner service, so access can be revoked individually without affecting the rest of the system.
Scale-up moving past a flat trusted network
A growing engineering team that used to trust anything inside the VPC starts enforcing service-to-service authentication as headcount and service count outgrow implicit trust.
Technology stack
- cert-manager
- step-ca
- Linkerd
- Istio
- SPIFFE/SPIRE
- SOPS
- Vault
Every subscription includes monthly DevOps, CyberSecurity and Programming hours: 1 h from the cPanel Advanced plan up, 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, and 10 h on GPU servers. Hours are requested from your client panel, don't roll over to the next month, and anything above the quota is accepted and billed separately.
Frequently asked questions
What is zero trust and why does it matter for internal services?
Zero trust means no connection is trusted just because it originates inside your network — every service has to authenticate itself, every time. It matters because a single compromised container or credential in a flat trusted network can otherwise reach everything else on it.
What's the difference between mTLS and regular TLS?
Regular TLS authenticates the server to the client — you know you're talking to the real server. Mutual TLS (mTLS) authenticates both sides, so the server also verifies the client's identity. Between internal services, that means one service can't impersonate another.
Do we need a full service mesh like Istio for this?
Not necessarily. A service mesh gives you mTLS plus traffic policy and observability, but adds a sidecar proxy per service and real operational overhead. For smaller architectures, mTLS without a full mesh often delivers the security property you actually need at lower complexity.
How often do certificates rotate, and does it require downtime?
Short-lived certificates typically rotate automatically every few hours to a few days, well before expiry, with no downtime — the rotation is designed to be transparent to the running service. We test this explicitly during set-up so a rotation failure doesn't surface as an outage.
What is workload identity, in plain terms?
It's an identity assigned to a running service itself, not to a network location or a shared credential — so 'the payments service' has its own verifiable identity regardless of which server or container it's running on at any given moment. This is what SPIFFE-style identity schemes formalise.
Where do secrets live if we're not trusting the network?
In a dedicated secrets manager (Vault) or encrypted directly in git (SOPS), never as plaintext environment variables assumed safe because the network is private. We set up one of these two approaches depending on your existing tooling and team size.
Still trusting anything inside your network by default?
Tell us your service architecture and we'll design the mTLS and identity model that closes that gap, using the hours already in your plan.