Zero trust architecture and cloud security design
Zero trust architecture is a design approach in which no user, device or network location is trusted by default. Every access request is checked against identity, device health and policy before it is allowed. We design it for your environment on AWS, Azure and Google Cloud and hand over a phased roadmap, not a shopping list.
What zero trust architecture means in practice
A zero trust architecture removes the assumption that anything inside the network can be trusted. Each request to a resource is decided on who is asking, from which device, for what, and it is decided again when any of those change.
The most widely cited reference is NIST Special Publication 800-207. It describes zero trust as moving defences away from static, network-based perimeters toward users, assets and resources. Its logical model separates a policy decision point, which decides whether a request is allowed, from a policy enforcement point, which sits in front of the resource and applies that decision.
In plain terms: a laptop on the office network gets no more access than the same laptop in a hotel, and a contractor who supports your payroll system reaches that system and nothing next to it.
The four layers we design across
- Identity. One authoritative directory, phishing-resistant MFA for administrators, conditional access, and privileged access that is granted for a task and then expires.
- Device. Device health as a sign-in condition: managed, patched, encrypted, with endpoint protection running.
- Network. Segmentation around the systems that matter most, restricted egress, and remote access that reaches named applications rather than a whole subnet.
- Application and data. Authorization enforced at the application, service-to-service identity for workloads, and logging that lets you see each decision after the fact.
The layers are designed together because each one covers for another. Strong MFA on an unmanaged device still hands a session to whoever controls the device.
Zero trust on AWS, Azure and Google Cloud
We design on AWS, Azure and Google Cloud, including estates that run on more than one, using each provider’s own identity, network and policy controls rather than a layer that hides them. Calls to a provider’s management APIs are already authenticated and authorized. The gaps tend to sit around that: long-lived access keys, flat virtual networks, and trust between accounts that nobody has reviewed.
To see what your environment permits today before designing the target, start with a cloud security configuration review. The findings feed straight into the roadmap.
A phased roadmap, not a product purchase
No. Many organizations already own the identity provider, device management and cloud controls a first phase needs, and the design starts from what is in place before anything new is bought. New tooling is recommended only where a specific gap is left after the existing controls are configured properly.
A typical sequence starts with identity and MFA, adds device health, then segments the most sensitive systems, and finishes with continuous verification and logging. Why that order works is set out in zero trust without buying a product. Where the design touches trust boundaries in your own software, it links to security architecture and threat modelling.
What you receive
| Deliverable | What it is for |
|---|---|
| Current-state assessment | Where implicit trust sits today, layer by layer |
| Target architecture | How identity, device, network and application controls fit together in your environment |
| Phased roadmap | Sequenced by risk reduced and disruption caused, with the owner of each step named |
| Design decisions record | Why each choice was made, so it survives staff changes |
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What is a zero trust architecture?
A zero trust architecture removes the assumption that anything inside the network can be trusted. Each request to a resource is decided on who is asking, from which device, for what, and it is decided again when any of those change.
Do we have to buy a zero trust product?
No. Many organizations already own the identity provider, device management and cloud controls a first phase needs, and the design starts from what is in place before anything new is bought.
Which cloud providers do you cover?
AWS, Azure and Google Cloud, including estates that run on more than one. Each is designed with the provider’s own identity, network and policy controls rather than with a layer that hides them.
How long does a zero trust roadmap take?
The design and roadmap take weeks. Delivering the roadmap is usually a programme of several phases over a year or more, and each phase is sized to close a named exposure rather than to complete a framework.
Start with where trust is implicit today
Describe your cloud providers, your identity provider and how remote access works now. The reply says what a design engagement would cover. See also all security services.