Secure by Design on Azure: Five Security Principles

Security added late is security with gaps. The decisions that would have closed those gaps were already made, months earlier, by people who had no security requirement in front of them at the time.

So by the time I turn up with an assessment template, most of the interesting work is archaeology.

Not testing. Archaeology.

Azure’s five security design principles are what having security in the room actually looks like: defence in depth, least privilege, secure by design, data classification and protection, and continuous security validation. All five sit on one model. Zero Trust. Never trust, always verify. Between them they settle one question, which is whether an environment’s security is a property of its architecture or a pile of controls stacked on after the design was frozen.

These map to the Security pillar of the Microsoft Azure Well-Architected Framework. They are also, conveniently, the architecture that satisfies NIS2 Article 21(2) and the relevant ISO 27001 Annex A controls. What follows takes each one into Azure practice. It is one of five companion walkthroughs under the architecture principles a real Azure assessment measures against.

Zero Trust runs on identity, not on your network diagram (C02)

Every request gets authenticated and authorised, wherever it comes from. That is the whole idea. There is no trusted internal network anymore, and network location stops carrying weight in an access decision.

On Azure the verification lives in identity, not at a perimeter. Concretely that means three things done together: identity management across every resource, micro-segmentation, and least-privilege access.

Microsoft Entra ID is the control plane. Conditional Access weighs user, device, location, and risk on every request. Privileged Identity Management hands out elevation just in time instead of leaving it lying around. Micro-segmentation comes from network security groups, Azure Firewall, and private endpoints, so a resource is not reachable simply because it happens to share a network with something else. Multifactor authentication is the floor here, not the ceiling. Microsoft’s own published numbers put the overwhelming majority of account compromises on accounts that never had MFA switched on at all.

Zero Trust is the model the other five principles implement. Defence in depth builds it at every layer. Least privilege is its access posture. Continuous validation keeps it honest.

Then there is the finding I write up over and over. A Conditional Access policy so riddled with exclusions that it has quietly rebuilt the perimeter it was meant to remove. A service-account group exempted from MFA. Open the group up and it holds human accounts.

Every time.

If you want to know where your own estate sits on that curve, the maturity view is in the Azure landing zone compliance review.

Defence in depth (S01)

No control should ever be the only control. That is the rule, and it costs something real: overlapping controls at four layers, plus the implementation and maintenance overhead redundancy always brings. You pay it on purpose.

On Azure the layers are concrete.

Network: network security groups, Azure Firewall, Azure DDoS Protection, private endpoints.

Host: Microsoft Defender for Servers, just-in-time VM access, disk encryption.

Application: Azure Web Application Firewall on Application Gateway or Front Door, plus managed identities so no application is holding a long-lived secret.

Data: encryption at rest, Azure Key Vault for keys and secrets, access controls scoped to classification.

Each layer assumes the one in front of it fails.

That assumption is the entire point.

What I find is almost always the lopsided estate. Heavy investment in one layer and very little behind it. A hardened network perimeter with nothing at the application layer. Strong identity sitting in front of data stores that are not encrypted. So here is the thing worth taking away, and it is not what most security dashboards imply: defence in depth is not the sum of your strongest control. It is the absence of a layer that has no control at all.

Least privilege tops every assessment I run (S02)

Grant access, forget to take it back. Do that for a few years and you have the single most common finding on Azure.

The principle is plain enough. Every user, service, and system runs on the minimum permissions its job actually needs. Living up to it is the hard part, because you have to understand what each role does, carry the administrative overhead of managing access, and run reviews on a schedule. Most shops handle the granting and quietly skip the reviewing.

Azure gives you the tools and does not make you use them. Role-based access control scoped tightly. Privileged Identity Management for just-in-time elevation instead of standing roles. Access reviews in Microsoft Entra ID Governance to catch the permissions that piled up and were never pulled back. An account holding elevated access only while it is using it is a smaller target than one carrying that access around the clock. Smaller attack surface, smaller blast radius.

The finding is the standing privileged role. A Global Administrator or Subscription Owner switched on permanently rather than activated when needed. It breaks least privilege as written into ISO 27001 Annex A.5.15 and the access-control expectations of NIS2 and DORA, and it lands near the top of my severity list every single time, for one reason. Compromise a standing-Owner account and you have compromised the subscription.

“But our admins need that access to do their jobs, and PIM is a licensing conversation we don’t want to have.”

Fair.

Both halves of that are true. Privileged Identity Management needs Microsoft Entra ID P2 licensing, and moving to it is a real migration effort, not a checkbox. Now say those two sentences out loud to a supervisor asking why standing administrative access exists across your production subscriptions. Neither one survives contact.

What you are protecting, and how you know it is still protected (S04, S05)

Two principles close the loop. One decides what you are protecting. The other checks, without pausing, that the protection is still there. Skip them and the other four are running blind.

Classification (S04) sorts data by sensitivity and protects it to match, across its whole lifecycle, because different data warrants different controls. On Azure that runs on Microsoft Purview for discovery and labelling, sensitivity labels that travel with the data, and encryption and access controls scoped to the label. GDPR Article 32 and ISO 27001 Annex A.5.12 both hang on getting this right. The finding writes itself. A storage account or database full of regulated personal data, protected exactly like everything else, because nobody ever classified it and so nobody ever differentiated its protection.

Validation (S05) tests controls continuously instead of assessing them once a year. Microsoft Defender for Cloud scores your posture continuously, vulnerability scanning rides along in the pipelines, and compliance gets evaluated in real time rather than in the week before an audit. That is the shift from a point-in-time snapshot to continuous assurance, and it is what NIS2 and DORA increasingly assume, because both treat security as a state you are in and not a certificate you renew.

This finding is a quieter one. Defender for Cloud switched on, alerts piling up, nobody acting on them. The tool is present. The governance loop that turns its findings into fixes is not.

Principle	Azure mechanism	Regulatory anchor	Common finding
Zero Trust (C02)	Microsoft Entra ID Conditional Access, PIM	NIS2 Art. 21(2)(i)	Conditional Access exclusions recreating the perimeter
Defence in depth (S01)	NSGs, Azure Firewall, WAF, Key Vault	ISO 27001 A.8.20	A layer with no control at all
Least privilege (S02)	Azure RBAC, PIM, access reviews	ISO 27001 A.5.15	Standing Owner / Global Administrator roles
Secure by design (S03)	Managed identities, pipeline security	NIS2 Art. 21(2)(e)	Security added after the design was frozen
Data classification (S04)	Microsoft Purview, sensitivity labels	GDPR Art. 32	Regulated data with undifferentiated controls
Continuous validation (S05)	Microsoft Defender for Cloud	DORA Art. 9	Defender deployed, findings unactioned

FAQ

Is Zero Trust a product I can buy for Azure? No. Zero Trust is a security model, never trust and always verify, built by configuring identity, network, and access services. On Azure that means Microsoft Entra ID Conditional Access, Privileged Identity Management, micro-segmentation, and continuous validation. No single product delivers it. The architecture does.

What is the single highest-impact Azure security change? For most environments, turning on Microsoft Entra ID Privileged Identity Management to remove standing privileged roles. Standing Global Administrator and Subscription Owner assignments are the most common high-severity finding and the most directly regulated, and just-in-time elevation closes the gap with the largest blast radius on Azure.

How does secure by design (S03) differ from the other principles? Secure by design is the timing principle. Security requirements get identified and addressed throughout the development lifecycle instead of bolted on at the end. It is less a specific control than the discipline that makes the other four achievable: managed identities, pipeline security, and threat modelling done early rather than retrofitted late.

Does continuous validation satisfy NIS2 and DORA? It satisfies the expectation that security is an ongoing state rather than a point-in-time assessment, which both regulations increasingly assume. Microsoft Defender for Cloud provides continuous posture assessment. The requirement is met not by deploying it but by acting on its findings through a governance loop that produces dated evidence of remediation.

Security that holds because it was designed in

Secure by design is not a slogan, although I have used it as one in enough slide decks to have lost the right to complain about that.

It is the observation that the security gaps an assessment finds are almost always design decisions nobody ever actually made. A perimeter trusted by default. A privileged role never revoked. Regulated data never classified. The five principles, anchored in Zero Trust, are how you make those decisions deliberately, at the point where they are still cheap.

The controls you end up with are simultaneously the security posture and the NIS2, DORA, and ISO 27001 evidence, because the architecture that resists an attacker is the same architecture that satisfies an examiner. That is the one thing to keep.

Design it in. It does not retrofit cleanly.