Azure SQL vulnerability assessments should run weekly (configured on subscription level with express configuration), but some databases are scanned monthly.

Question

Azure SQL vulnerability assessments should run weekly (configured on subscription level with express configuration), but some databases are scanned monthly. The weekly vulnerabiilty reports randomly show databases. In my case, I have 5 databases, and the report displays only 1, 2 or 3 databases randomly. Also the scan history in the azure portal shows that some databases are only scanned once a month. We are paying for this service, so can someone look into this? If needed I can provide evidence privately. Thanks.

Answer 1

Hi Rogier Haest,

Thanks for your patience. After further investigation, this behavior is confirmed to be caused by a known service-side issue affecting Azure SQL Vulnerability Assessment (VA) recurring scans.

Due to a recent incident, recurring VA scans were temporarily disabled by Microsoft in several regions, including East US, East US 2, and West Europe, to prevent excessive load on the SQL control plane. This was a protective action taken after a regression related to a performance fix.

As a result, you may observe:

Weekly recurring scans not running consistently
Some databases being scanned monthly instead of weekly
Weekly VA reports showing only a subset of databases
Inconsistent scan history across databases

This behavior is not caused by your configuration and not specific to your subscription or databases.

Until the issue is fully resolved, you can continue to run vulnerability assessments manually using any of the supported methods:

Azure Portal → SQL Database → Vulnerability Assessment → Scan

https://docs.microsoft.com/en-us/powershell/module/az.sql/start-azsqldatabasevulnerabilityassessmentscan?view=azps-7.2.0

https://docs.microsoft.com/en-us/rest/api/sql/2020-11-01-preview/database-vulnerability-assessment-scans/initiate-scan

No action will be required once the issue is resolved. Recurring scans will automatically resume when the fix is re-enabled across the affected regions.

We understand the concern, especially since this is a paid service, and appreciate your understanding while the engineering team completes remediation.

Answer 2

Hello Rogier Haest,

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

I understand that your Azure SQL vulnerability assessments should run weekly as configured on subscription level with express configuration, but some databases are scanned monthly.

Microsoft confirmed this issue is a service‑side outage, where recurring Vulnerability Assessment scans were temporarily disabled in several regions due to a performance regression. The inconsistent scan behavior is expected during this incident, and no customer configuration changes are required. Weekly scans will automatically resume once Microsoft restores full functionality. - https://docs.microsoft.com/en-us/powershell/module/az.sql/start-azsqldatabasevulnerabilityassessmentscan?view=azps-7.2.0

During the outage, you can still run manual scans through the Azure Portal under SQL Database > Security > Vulnerability Assessment > Scan, or by using PowerShell:

Start-AzSqlDatabaseVulnerabilityAssessmentScan -ResourceGroupName "YourRG" -ServerName "YourServer" -DatabaseName "YourDB"

You may also trigger scans via the REST API endpoint: POST /databaseVulnerabilityAssessmentScans/initiate-scan, with no additional remediation or storage adjustments needed. - https://docs.microsoft.com/en-us/rest/api/sql/2020-11-01-preview/database-vulnerability-assessment-scans/initiate-scan

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.

Answer 3

I've accepted the answer, but since it's only an explanation I would like to add the remark that I find it very unprofessional that a critical security (paid!) service like this is disabled without any further notice to the actual users of this service. So I strongly suggest Microsoft to actively communicate these kinds of incidents.