microsoft defender for cloud not accounting for network security perimiter (NSP) settings in secure score

Question

we have recommendations to use private link for our key vault and storage accounts that are bringing our secure score down by 19-81% which is below the 95% that TRIP, our security team, requires.   We use a network security perimiter already in enforced mode so public access is disabled by default. This approach has been thoroughly vetted by TRIP. they've asked us to create a support ticket to understand why this is still needed and if the secure score does not account for this newer service in azure that we are using

Answer 1

Hello Brandon Holt (BEYONDSOFT CONSULTING INC),

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Microsoft defender for cloud not accounting for network security perimeter (NSP) settings in secure score.

Even though you already enforce Network Security Perimeter (NSP) to block public access. This isn’t a misconfiguration because, Secure Score only credits built‑in recommendations from the Microsoft Cloud Security Benchmark (MCSB), and NSP isn’t yet counted as an equivalent control for those private‑endpoint checks, so the items remain unhealthy and keep lowering the score until you either meet the mapped control or formally exempt it. See Secure Score model & MCSB mapping and Regulatory compliance/MCSB overviews; for NSP’s enforcement model and properties, review the official concept article for more details.

You have two precise, supported paths:

Path A (implementation):

Deploy Private Endpoints for Key Vault and Storage and explicitly disable public network access on those resources; this satisfies the mapped MCSB controls and raises Secure Score after the next evaluation cycle. Use Key Vault + Private Link guidance and Storage + Private Endpoints guidance and remember that creating a Private Endpoint does not automatically block the public endpoint, and you must set PublicNetworkAccess = Disabled. (You can also enforce this at scale with the built‑in policy to disable storage public access.)

Path B (governance):

Keep NSP Enforced and create Defender for Cloud exemptions for the affected recommendations (mark Mitigated with justification “NSP Enforced - public access blocked”). This removes their impact on Secure Score while retaining your current architecture and documents the compensating control for audit. - https://docs.digicert.com/en/certcentral/manage-certificates/certcentral-key-size-restrictions-for-private-ssl-tls-certificates.html, and - https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/ecdsa-rsa-certificates

Finally, if you choose Path A, create the Private Endpoints per the docs above and immediately lock down public access as an example CLI below for the lock‑down step:

# Disable public network access after Private Endpoints are in place
az storage account update -g <rg> -n <storageAccount> --public-network-access Disabled
az keyvault update  -g <rg> -n <keyVaultName>   --public-network-access Disabled

Then validate Private DNS resolution (privatelink.*) per each service’s guide; Secure Score recalculates roughly every eight hours.

If you choose Path B, open each recommendation in Defender for Cloud > Exempt > scope (resource/subscription/MG) > Mitigated > add justification referencing NSP Enforced, and retain NSP diagnostics as evidence. - https://stackoverflow.com/questions/79672288/problem-setting-azure-application-gateway-to-use-certificate-held-in-azure-key-v, - https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/ecdsa-rsa-certificates, and - https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints gives more insight.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.