CNAPP and Azure Architecture: Where Runtime Risk Detection Stops and Design Review Begins

A Cloud-Native Application Protection Platform — Microsoft Defender for Cloud is the Azure-native one — tells you which resources are misconfigured, over-permissioned, or exploitable right now, and ranks them by how reachable an attacker would find them. That is necessary work, and it is downstream work. It operates on the architecture you already built. It does not ask whether that architecture should have been built the way it was — whether a component should exist at all, whether two systems should be coupled the way they are, or what the blast radius is when one of them fails. Those are design-time questions, and a CNAPP is not where they get answered.

Microsoft’s own framing makes the distinction visible. Their recent positioning of CNAPP centres on prioritising exploitable risk — reducing exposure, ranking what to fix first, operationalising response across the application lifecycle. Read that carefully and the boundary is in plain sight. Prioritising exploitable risk presumes the risk already exists in your running environment. It is detection and triage. It is the smoke alarm, correctly tuned, telling you which room is on fire first.

The architecture question is upstream of the alarm: why is the room laid out so that a fire there reaches the server cupboard at all?

Key takeaways

• A CNAPP evaluates your running environment — posture, workload protection, entitlements, exploitable paths — and prioritises what to remediate. It is detection and triage, and it is genuinely valuable.
• An architecture assessment evaluates design decisions — whether components should relate the way they do, what the failure blast radius is, and whether the reasoning was ever documented. It runs upstream of the CNAPP.
• The two are complementary, not competing. A CNAPP finds the unlocked door; an architecture review asks why the blueprint put a door there in the first place.
• For NIS2 and DORA, supervisors increasingly ask for the design rationale, not only the current posture score — the architecture decision records, the documented risk acceptance, the mapping to WAF security principles and Annex A controls.
• Neither layer replaces the other. Runtime detection without design review chases symptoms; design review without runtime detection misses what changed yesterday afternoon.

What a CNAPP actually evaluates

A CNAPP consolidates several capabilities that used to ship as separate tools: cloud security posture management (is this resource misconfigured against a benchmark?), cloud workload protection (is this VM or container being attacked?), and entitlement management (does this identity have more access than it needs?). Defender for Cloud brings these together for Azure, scores your posture, and — this is the part Microsoft is emphasising — ranks findings by exploitability so a finite team fixes the reachable critical path before the theoretical one.

This is good engineering. A storage account exposed to the public internet with a reachable attack path is a different priority from one exposed only inside a segmented virtual network, and a tool that knows the difference saves real hours. If you run regulated workloads on Azure and you do not have a CNAPP capability switched on, that is a gap worth closing before you read any further. (For a fair, Defender-specific read of exactly where the regulatory compliance dashboard covers and where it stops, see Defender for Cloud and the NIS2/DORA gaps.)

But notice what every one of those findings has in common. They are statements about the current state of resources that already exist. The storage account is public. The identity is over-permissioned. The container has a known CVE. Each is true of the environment as it is running this minute. Fix them all and your posture score goes up. None of them tell you whether the system was sound by design.

The question a posture score cannot answer

Here is a finding a CNAPP will not produce, because it is not a runtime fact: this payment-processing workload shares a data tier with a reporting workload, the coupling was never documented, and a failure or compromise in the low-sensitivity reporting path now has a route into the high-sensitivity payment path.

Every individual resource in that example can be perfectly configured. No misconfiguration, no exposed secret, no over-broad role — a clean posture score. And the architecture is still wrong, because the design coupled two things that should have been isolated, and nobody recorded the decision, so nobody revisited it. That is a system-level property. It lives in the relationships between components, not in the configuration of any one of them. Posture management looks at the components. It does not reason about the system.

This is the distinction that matters under regulatory scrutiny. A NIS2 supervisor or a DORA examiner asking about ICT risk management is not satisfied by a high Secure Score. They ask why the architecture is defensible: what your segmentation model is and why, where your single points of failure are and whether you accepted them deliberately, which design decisions were made and on what basis. Those are answered by architecture decision records and a structured Well-Architected assessment — not by a list of remediated misconfigurations, however long and well-prioritised.

Why teams conflate the two — and what it costs

The conflation is understandable. Both a CNAPP and an architecture assessment produce findings about your Azure environment, both map to compliance frameworks, and both end in a remediation list. From a distance they look like the same product at different price points.

They are not. They answer different questions, and a team that owns only the runtime layer ends up in a predictable place: continuously remediating symptoms while the underlying design generates new ones. The public storage account gets locked down. Three months later a different team stands up a similar pattern, because the pattern was never the problem the tool was built to see — the tool sees instances, not patterns. The posture score stays respectable. The architecture keeps drifting, because configuration drifts away from intended design continuously, and the layer that would catch a design regression is not running.

The cost is not usually a breach. More often it is the audit conversation that goes badly — the one where the examiner asks for the architectural reasoning behind a control and the honest answer is “Defender says we’re at 82%.” That is a posture answer to a design question, and a sophisticated examiner hears the mismatch immediately.

How the two layers fit together

The right model is a stack, not a choice.

Design-time, an architecture assessment establishes whether the system is sound: it evaluates the design against the Well-Architected Framework, documents the decisions and the accepted risks, and produces the structured evidence — control mappings, decision records, gap analysis — that a supervisor asks for. This is the layer that answers “should it be built this way,” and it is where compliance evidence that survives an audit is actually generated.

Runtime, the CNAPP establishes whether the running environment matches a secure posture and prioritises what to fix when it does not. This is the layer that answers “is anything exploitable right now,” and it is indispensable for exactly that.

Between them sits drift. The architecture you assessed and documented is not the architecture running six months later. The CNAPP catches the resource-level changes — a new exposure, a fresh CVE. A design-level regression — a new coupling, an undocumented dependency, a control that was quietly removed — needs the design layer to run again, not just the posture scan. Run both, on their own cadences, and you have coverage from blueprint to runtime. Run only one and you have a known blind spot.

This is where producing the design-layer evidence stops being a manual exercise. Platform Architecture Authority (PAA) reads your Azure configuration via Resource Graph, assesses it against the Well-Architected Framework, maps the gaps to NIS2, DORA, ISO 27001 Annex A, and SOC 2, and generates the architecture decision records and remediation code that a design review is supposed to produce — in a single session rather than a multi-week engagement. It sits upstream of your CNAPP, not in competition with it: PAA does not do runtime threat detection or workload protection, and it is not trying to. It is read-only, and it answers the design question your posture tool was never built to answer. The two outputs are complementary, and an audit file is stronger for having both.

FAQ

Is PAA a CNAPP or a CSPM tool? No. A CNAPP, including Defender for Cloud, evaluates your running environment for exploitable risk and prioritises remediation — runtime detection and triage. PAA assesses your architecture design against the Well-Architected Framework, produces compliance-mapped documentation and architecture decision records, and runs upstream of the CNAPP. They answer different questions and work well together; PAA does not replace your posture management, and your posture management does not produce design evidence.

If my Secure Score is high, isn’t my architecture sound? Not necessarily. A high posture score means your individual resources are well-configured against the benchmarks. It says nothing about system-level design — whether components are coupled in ways that create blast radius, whether single points of failure were accepted deliberately, or whether the reasoning was documented. Those are design properties a posture score does not measure.

Do I need both runtime detection and design assessment? For regulated Azure workloads, yes. Runtime detection without design review chases symptoms the architecture keeps regenerating. Design review without runtime detection misses the exposure that appeared yesterday afternoon. NIS2 and DORA examiners increasingly ask for both the current posture and the design rationale behind it.

What does an examiner actually ask for that a CNAPP can’t supply? The architectural reasoning: your segmentation model and why, your documented single points of failure and accepted risks, the design decisions and their basis, mapped to the relevant controls. That is architecture decision records and a structured WAF assessment, not a prioritised list of remediated misconfigurations.

A useful test before your next audit: ask your team why a given high-sensitivity workload is coupled the way it is, and whether the decision was ever written down. If the answer is the current posture score, you have found the gap — and it is upstream of the tool you were pointing at it.