CLOUDMECHANIX
Consulting

Azure security & Zero Trust.

Being in Azure doesn't make you secure. We design identity-first environments that assume breach: every request is verified, the network is segmented, and access is least-privilege by default. The result is a security model your team can explain to the board and defend to an auditor.

The problem

You'll recognise this.

You're in Azure and the Microsoft security tools are switched on. But when the board asks whether you would survive a breach, or an auditor asks how access is actually controlled, you can't give a straight answer. Security was bought, not designed.

The usual signs: standing administrator rights because it was easier, a flat network where one compromised workload can reach the rest, and conditional access that was configured once and never revisited. None of it is wrong on its own. Together, it means you can't prove where you stand.

What you get

Senior depth, handed over.

  • A Zero Trust design for your Azure estate — identity, network segmentation and conditional access.
  • Controls mapped to what you're actually asked about: NIS2, ISO 27001 and the Well-Architected Framework.
  • A security model your team understands and can run, with the documentation to back it up.
How we'd approach it

The decisions that matter.

Identity is the perimeter.

Why: Users, services and devices connect from everywhere. The network edge no longer contains anything worth defending, so every request is verified — who, from what device, in what state — before it is allowed.

What we'd rule out: A firewall-only model that treats everything inside the VNet as trusted.

Assume breach, and segment for it.

Why: A flat network turns one compromised workload into all of them. Segmentation and inspected east-west paths mean a foothold stays a foothold instead of becoming an incident.

What we'd rule out: A single large network with open traffic between everything for convenience.

Least privilege with just-in-time access, not standing admin.

Why: Permanent Owner and Contributor rights are exactly what an attacker looks for. Privileged Identity Management grants elevated access for a task, for a window, with an audit trail.

What we'd rule out: Permanent role assignments because requesting access each time feels slow.

What you get

Deliverables.

  • A Zero Trust design for your Azure estate: identity, conditional access, and network segmentation.
  • A conditional access policy set, documented and explained.
  • A privileged-access model using Entra ID and PIM.
  • A mapping of the controls to NIS2 and ISO 27001, so you can answer the audit question.
  • Design documentation and a walkthrough, so your team can run and defend it.
Out of scope

What it isn't.

  • It is not a managed detection and response service — running the SOC day to day is Security Operations & Management.
  • It is not a penetration test.
  • It is not endpoint or device management beyond what Entra ID and Intune policy cover.
  • Incident response on retainer is a separate arrangement.
The shape of it

How it fits together.

Who is asking

  • Zero Trust principle:
  • Verify explicitly
  • Peopleemployees, contractors, third parties
  • Devicesmanaged and unmanaged endpoints
  • Workload identitiesmanaged identities and service principals

Microsoft Entra ID — every request is evaluated here

  • Zero Trust principle:
  • Verify explicitly
  • Use least privilege access
  • Conditional Access
  • Multifactor authentication
  • Azure RBAC
  • Privileged Identity Management — just-in-time access

Evaluated against user risk, device health, location and workload context.

Segmented workloads

  • Zero Trust principle:
  • Assume breach

No lateral path between segments.

  • ProductionIts own segment, its own policy.
  • Non-productionIts own segment, its own policy.
  • Shared platform servicesIts own segment, its own policy.
  • Data and backupIts own segment, its own policy.
Identity is the control plane. Every request is verified explicitly, granted least privilege, and lands in a segment that assumes breach.
How we work

With your team, not around them.

We start from your identities and your data, not a product list. We agree the segmentation and the controls with you, then build them alongside your team so they know why each decision was made.

Who it's for: We work with mid-to-large enterprise, State and semi-State bodies, education, and the partner consultancies who bring us in when a client needs senior Azure depth.

Questions

Frequently asked.

Is Zero Trust a product we have to buy?
No. It is a design principle. We implement it with tools you already have or licence — Entra ID, conditional access, network segmentation and Microsoft Defender — configured to work together.
Do we have to rebuild everything at once?
No. We sequence it. Identity and privileged access usually come first, then segmentation, then the rest. Each step stands on its own.
Does this make us NIS2 compliant?
It maps your controls to NIS2 and ISO 27001 and closes the gaps, so you can evidence where you stand. Formal certification is a separate process.
Will conditional access get in our users’ way?
Done properly, it is invisible to a compliant user on a healthy device. The friction lands on risky sign-ins, which is the point.
Who runs it after you leave?
Your team. We build it alongside them and hand over the design and the policies, so they understand why each control exists.
How long does it take?
A design is a matter of weeks; rollout is sequenced around your estate and your change process. We scope it before we start.
Proof

Proof

We built a Zero Trust Azure network for Lakeland Dairies — hub-and-spoke, Azure Firewall, across two regions, delivered in a 21-day engagement. Read the case study.

Talk to an Azure architect, not a salesperson.

Fixed scope, fixed price — quoted on enquiry.