NIS2 Supply Chain Security for Azure and Microsoft 365
NIS2 supply chain security on Azure means governing OAuth apps, service principals, and SaaS dependencies under Article 21(2)(d). What to configure and evidence. For CISOs.
Marc Dekeyser |
NIS2 Supply Chain Security for Azure and Microsoft 365
NIS2 supply chain security on Azure is the obligation, under Article 21(2)(d), to govern the security of your suppliers and service providers — and in a Microsoft Azure and Microsoft 365 estate, your largest supplier surface is not a list of vendors in a procurement spreadsheet. It is the set of OAuth applications, service principals, and SaaS integrations that already hold consented access to your tenant. NIS2 supply chain security on Azure means treating those grants as the in-scope third-party dependencies they are, and producing evidence that you govern them.
Most organizations can name their top ten vendors. Far fewer can produce, on demand, a list of every enterprise application in Microsoft Entra ID that holds delegated or application permissions to Microsoft 365 data — including the ones a user consented to two years ago and no one has reviewed since. That gap is the practical shape of supply chain risk in the cloud.
Key takeaways
- NIS2 Article 21(2)(d) requires entities to address security in supplier relationships, including the security of the supply chain and the relationships between each entity and its direct suppliers or service providers.
- In a Microsoft 365 estate the in-scope supply chain includes Microsoft Entra ID enterprise applications, app registrations, OAuth consent grants, and service principal credentials — not only contracted SaaS vendors.
- Microsoft Defender for Cloud flags non-compliant and third-party resources against regulatory standards; Microsoft Defender for Containers scans images for known vulnerabilities before and after deployment.
- A Software Bill of Materials (SBOM) is becoming a baseline expectation for software suppliers; the EU Cyber Resilience Act formalizes it for products with digital elements.
- Microsoft itself is a dependency — concentration risk that NIS2’s supply-chain logic expects you to acknowledge, not ignore.
What does NIS2 Article 21(2)(d) actually require of suppliers?
NIS2 Article 21(2)(d) requires that your risk-management measures address supply chain security, including security-related aspects of the relationships between your entity and its direct suppliers or service providers. The directive expects you to consider the specific vulnerabilities of each supplier, the overall quality of their products and cybersecurity practices, and their secure development practices.
The phrasing matters in two ways. First, it is about direct suppliers and service providers — you are not asked to audit your suppliers’ suppliers to infinite depth, but you are squarely responsible for the entities you contract with and integrate. Second, it is risk-based: a supplier with deep access to your most sensitive systems warrants more scrutiny than a low-impact tool.
In a Microsoft Azure and Microsoft 365 context, “direct supplier or service provider” extends past the procurement-led vendor list. An OAuth application that a user granted Mail.Read across the tenant is, functionally, a service provider with standing access to corporate email. NIS2 does not exempt it because no purchase order exists. This connects directly to incident duties — a compromised supplier integration is one of the most common roots of a reportable event, which is why NIS2 incident reporting on Azure and supply-chain governance are two halves of the same control story.
Which Azure and Microsoft 365 dependencies are in scope?
The in-scope dependencies are every identity and integration that can act in your tenant: Microsoft Entra ID enterprise applications, app registrations, OAuth consent grants, service principals, managed identities with elevated roles, and the SaaS and managed services connected to them. Each is a path through which a third party touches your data, and each is therefore part of the supply chain Article 21(2)(d) covers.
The categories that generate the most unmanaged risk:
- OAuth consent grants. When user consent is left enabled, individuals can grant third-party applications access to Microsoft 365 data without review. The control is to restrict user consent in Microsoft Entra ID to verified publishers and low-impact permissions, and route the rest through an admin consent workflow.
- Over-privileged service principals. Application registrations frequently accumulate permissions like
Directory.ReadWrite.AllorMail.Sendthat exceed what the integration needs. Each is a standing grant to an external party. - Stale and long-lived credentials. Client secrets and certificates on app registrations that never expire, or that outlive the integration, are a supply-chain exposure. Microsoft Entra ID can report credential age and expiry per application.
- Third-party SaaS and managed services. Connected platforms — monitoring, backup, productivity add-ins — that authenticate into the tenant and read or write data.
The artifact this control set produces is an enterprise application inventory: every application, its permissions, its consent type, its credential status, and its owner. That inventory is what an assessor asks for when they test Article 21(2)(d), and it is what most teams cannot produce on the day.
How do Microsoft Defender for Cloud and Defender for Containers help?
Microsoft Defender for Cloud and Microsoft Defender for Containers turn supply-chain governance from a periodic manual review into a continuously evaluated posture. Defender for Cloud assesses your resources against regulatory and security standards and flags non-compliant or third-party resources; Defender for Containers scans container images for known vulnerabilities, which is where most software supply-chain exposure actually lives.
What each produces, concretely:
| Control | Microsoft service | Artifact produced |
|---|---|---|
| Posture against standards | Microsoft Defender for Cloud — regulatory compliance dashboard | Per-control pass/fail mapped to NIS2-aligned and CIS/ISO standards |
| Vulnerable dependencies in images | Microsoft Defender for Containers image scanning | CVE findings per image, pre- and post-deployment |
| Over-privileged identities | Microsoft Entra ID + Defender for Cloud recommendations | List of identities/apps exceeding least privilege |
| Exposed secrets / keys | Defender for Cloud secret scanning | Findings of credentials in resources |
Defender for Containers scans images both in the registry and at runtime, so a base image that was clean at build time but has since accrued a published CVE is re-flagged. That continuous re-evaluation is the difference between a point-in-time scan and a supply-chain control. The Azure configuration drift discussion covers how third-party changes erode a known-good baseline over time.
One honesty note: these tools surface findings. They do not decide which third-party integration is acceptable for your risk appetite, and they do not negotiate a supplier’s remediation. That judgment stays with a human who understands the business context.
What about SBOMs and Microsoft as a dependency?
A Software Bill of Materials (SBOM) is an inventory of the components inside a piece of software, and it is moving from optional to expected — the EU Cyber Resilience Act sets SBOM and vulnerability-handling obligations for products with digital elements, and NIS2’s supply-chain duty makes asking suppliers for one a reasonable, evidenceable control. An SBOM lets you answer “are we exposed to this newly-disclosed component vulnerability?” without waiting for each vendor to volunteer the answer.
For software you build and ship from Azure, you can generate an SBOM in the build pipeline — for example as part of an Azure DevOps or GitHub Actions workflow — and retain it as the artifact that proves you know what is in your own product. For software you consume, the control is to require an SBOM from material suppliers and to track it.
Then there is the dependency most NIS2 supply-chain analyses quietly skip: Microsoft. Microsoft Azure, Microsoft Entra ID, and Microsoft 365 are themselves a concentrated supplier. NIS2’s supply-chain logic does not ask you to remove that dependency. It asks you to acknowledge the concentration, understand the shared-responsibility boundary, and have a position on resilience: what you control, what Microsoft controls, and what you do when the platform itself has an incident. Naming the dependency is part of the evidence, not an admission of weakness.
How do you produce the evidence an assessor expects?
You produce the evidence by turning each control into a retained, dated artifact: the enterprise application inventory, the consent configuration, the Defender for Cloud compliance export, the container scan results, and the supplier SBOMs. An assessor testing Article 21(2)(d) does not want a policy that says you manage suppliers; the assessor wants the list, the configuration, and the dates that show you actually do.
The minimum evidence set for a Microsoft 365 and Azure estate:
- Microsoft Entra ID enterprise application inventory with permissions, consent type, and credential expiry.
- The tenant’s user-consent and admin-consent configuration, showing consent is restricted.
- A Microsoft Defender for Cloud regulatory compliance export, dated, with non-compliant third-party resources identified.
- Microsoft Defender for Containers scan results showing image vulnerability status over time.
- Supplier SBOMs and a register of material suppliers with their access scope.
Assembling that set by hand, across a real tenant, is where the work actually is — and where it tends to lapse between audits. Platform Architecture Authority (PAA) reads your Microsoft Entra ID and Microsoft Azure configuration, surfaces the over-privileged service principals, the unreviewed consent grants, and the non-compliant third-party resources, maps them to Article 21(2)(d), and generates the remediation code you apply. PAA is read-only and does not change your tenant; a senior reviewer still owns the call on which supplier risk is acceptable.
FAQ
Are OAuth apps really in scope for NIS2 supply chain security? Yes. An OAuth application with consented access to Microsoft 365 data is functionally a service provider with standing access to your systems, which places it within the supplier relationships Article 21(2)(d) covers. The absence of a procurement contract does not remove it from scope. Govern consent grants and service principals as part of your supply chain.
Does NIS2 require an SBOM? NIS2 does not name SBOMs explicitly, but its supply-chain duty makes requesting one from material software suppliers a defensible, evidenceable control. The EU Cyber Resilience Act does set SBOM and vulnerability-handling obligations for products with digital elements, so SBOMs are becoming a baseline supplier expectation regardless of which instrument you cite.
How is supply chain different from general security under NIS2? General security measures protect your own systems; supply chain security under Article 21(2)(d) addresses the risk your suppliers and service providers introduce through their access and their own practices. In a cloud estate that means governing the identities and integrations third parties hold in your tenant, not only hardening infrastructure you operate directly.
Can Microsoft Defender for Cloud prove NIS2 compliance on its own? No. Microsoft Defender for Cloud produces strong posture evidence — a regulatory compliance dashboard, per-control results, and third-party resource findings — but it does not cover supplier contracts, SBOM collection, or the risk judgments behind which integrations you accept. It is a major part of the evidence set, not the whole of it.
Should we treat Microsoft as a supply-chain risk? Yes, as a concentration risk to acknowledge rather than to eliminate. NIS2’s supply-chain logic expects you to understand the shared-responsibility boundary with Microsoft, know what you control versus what the platform controls, and hold a position on resilience when the platform itself has an incident. Naming the dependency is part of the evidence.
The supply chain in a Microsoft cloud estate is mostly invisible until you enumerate it. Enumerate it first, govern the access second, and keep the inventory current — because the controls Article 21(2)(d) describes are only as real as the evidence you can produce on the day.
