CMMC / NIST 800-171 Readiness

CMMC Level 2 / NIST SP 800-171 Rev 2 automated readiness estimate

Tenants: Contoso Retail (22222222-3333-4444-5555-666666666666), Fabrikam Engineering (33333333-4444-5555-6666-777777777777), Zava Demo (11111111-2222-3333-4444-555555555555) | Generated 2026-10-08 13:48

SPRS Readiness Estimate

52 / 110

SPRS scores range from -203 (worst) to 110 (best). Following the DoD assessment methodology, the estimate starts at 110 and subtracts each unmet requirement's weight (1, 3, or 5 points). This scan deducted 58 points, so a score below zero means the deductions exceed the 110 starting points; it is common before remediation and rises as gaps are fixed or attested.

CMMC Level 1: 4/9 assessable practices passing

Passed by automated evidence

Manual attestation required (total)

Attestation controls with scan findings; these deduct SPRS points

Attestation controls without automated evidence; no deduction

Not applicable

Automated-evidence readiness estimate for the Microsoft 365 / Entra / Intune / Purview subset. Not an official DoD assessment or a substitute for a C3PAO. Every requirement is graded Pass or Manual Attestation Required; controls Siemserva cannot verify are never counted as passing. Where the scan surfaced findings, the control's SPRS weight is deducted from the estimate until the gap is remediated or attested.

Next Steps: Fastest Path to a Passing Score

The actions below are ordered to raise the SPRS estimate as quickly as possible. Each action fixes every finding of one Siemserva check. The ranking weighs three things: how many SPRS points the action recovers (a requirement's deduction is only recovered once every check gapping it is fixed, so an action that is the sole gap on a requirement pays off immediately), how many requirements the action advances, and how much work it is (built-in per-finding remediation time estimates). Requirements that can only be manually attested deduct nothing from this automated estimate and are listed as a separate track below; their real cost varies from documentation only (the practice already exists and just needs evidence) to genuine process build-out.

Estimate today

110

After completing all remediation steps

Remediation actions

5.3 h

Total estimated effort

Step	Action	Est. Effort	Findings	Points Recovered	Requirements Completed	Requirements Advanced	Score After
1	Secret Expired rotate expired secret	20 min	1	+10	3.1.1, 3.1.2	3.4.9	62
2	Autopatch Deployment Reboot Delay Long tighten Autopatch reboot deadline	30 min	3	+0	(shared gaps remain)	3.4.2, 3.4.6, 3.4.7, 3.4.8, 3.4.9, 3.8.7, 3.8.8, 3.14.4, 3.14.5	62
3	Autopatch Updatable Asset Group Not Enrolled enroll Entra group devices with deployment service	45 min	3	+0	(shared gaps remain)	3.4.2, 3.4.6, 3.4.7, 3.4.8, 3.4.9, 3.8.7, 3.8.8, 3.14.4, 3.14.5	62
4	Autopatch Deployment No Members fix empty Autopatch deployment audience	45 min	3	+37	3.4.2, 3.4.6, 3.4.7, 3.4.8, 3.4.9, 3.8.7, 3.8.8, 3.14.4, 3.14.5	none	99
5	Intune Device Vulnerability Kev patch device for KEV-listed vulnerability	1.5 h	2	+0	(shared gaps remain)	3.11.2, 3.11.3, 3.14.1	99
6	Intune Device Vulnerable Software update vulnerable software product	1.5 h	3	+11	3.11.2, 3.11.3, 3.14.1	none	110

A step with "(shared gaps remain)" still matters: it is a prerequisite that later steps build on. Effort figures are per-finding estimates times the finding count; a single tenant-wide policy change can cover many findings at once, so treat them as an upper bound for planning.

Then: the manual attestation track

These requirements cannot be verified automatically, so they do not deduct from the estimate above; in an official self-assessment, however, each one only counts when you can attest to it with evidence. They are ordered easiest-first: requirements whose evidence check ran but could not read the data are usually quick (grant the scanner's missing permission or fix the unreadable setting, then re-scan to turn them into machine evidence), then the rest by descending SPRS weight so the highest-value attestations are prepared first. For each, the effort is small when the practice already exists (collect the policy or record and attest) and large when the practice must be built.

Attestation-only requirements (51), highest SPRS weight first.

NIST	CMMC Practice	Family	SPRS Weight	Basis
3.1.16	AC.L2-3.1.16	Access Control	5	Inherently manual (people, physical, or process evidence)
3.10.1	PE.L1-3.10.1	Physical Protection	5	Inherently manual (people, physical, or process evidence)
3.12.1	CA.L2-3.12.1	Security Assessment	5	Inherently manual (people, physical, or process evidence)
3.12.3	CA.L2-3.12.3	Security Assessment	5	No automated Siemserva check covers this control yet
3.13.11	SC.L2-3.13.11	System and Communications Protection	5	No automated Siemserva check covers this control yet
3.13.2	SC.L2-3.13.2	System and Communications Protection	5	Inherently manual (people, physical, or process evidence)
3.13.5	SC.L1-3.13.5	System and Communications Protection	5	Inherently manual (people, physical, or process evidence)
3.13.6	SC.L2-3.13.6	System and Communications Protection	5	Inherently manual (people, physical, or process evidence)
3.14.2	SI.L1-3.14.2	System and Information Integrity	5	Inherently manual (people, physical, or process evidence)
3.2.1	AT.L2-3.2.1	Awareness and Training	5	No automated Siemserva check covers this control yet
3.2.2	AT.L2-3.2.2	Awareness and Training	5	No automated Siemserva check covers this control yet
3.3.5	AU.L2-3.3.5	Audit and Accountability	5	Inherently manual (people, physical, or process evidence)
3.7.2	MA.L2-3.7.2	Maintenance	5	Inherently manual (people, physical, or process evidence)
3.7.5	MA.L2-3.7.5	Maintenance	5	Inherently manual (people, physical, or process evidence)
3.8.3	MP.L1-3.8.3	Media Protection	5	No automated Siemserva check covers this control yet
3.9.2	PS.L2-3.9.2	Personnel Security	5	Inherently manual (people, physical, or process evidence)
3.1.19	AC.L2-3.1.19	Access Control	3	Inherently manual (people, physical, or process evidence)
3.11.1	RA.L2-3.11.1	Risk Assessment	3	Inherently manual (people, physical, or process evidence)
3.12.2	CA.L2-3.12.2	Security Assessment	3	Inherently manual (people, physical, or process evidence)
3.12.4	CA.L2-3.12.4	Security Assessment	3	Inherently manual (people, physical, or process evidence)
3.13.4	SC.L2-3.13.4	System and Communications Protection	3	Inherently manual (people, physical, or process evidence)
3.13.8	SC.L2-3.13.8	System and Communications Protection	3	Inherently manual (people, physical, or process evidence)
3.13.9	SC.L2-3.13.9	System and Communications Protection	3	Inherently manual (people, physical, or process evidence)
3.4.4	CM.L2-3.4.4	Configuration Management	3	Inherently manual (people, physical, or process evidence)
3.5.10	IA.L2-3.5.10	Identification and Authentication	3	No automated Siemserva check covers this control yet
3.7.1	MA.L2-3.7.1	Maintenance	3	Inherently manual (people, physical, or process evidence)
3.7.4	MA.L2-3.7.4	Maintenance	3	Inherently manual (people, physical, or process evidence)
3.8.5	MP.L2-3.8.5	Media Protection	3	No automated Siemserva check covers this control yet
3.8.6	MP.L2-3.8.6	Media Protection	3	No automated Siemserva check covers this control yet
3.9.1	PS.L2-3.9.1	Personnel Security	3	Inherently manual (people, physical, or process evidence)
3.1.21	AC.L2-3.1.21	Access Control	1	Inherently manual (people, physical, or process evidence)
3.1.22	AC.L1-3.1.22	Access Control	1	Inherently manual (people, physical, or process evidence)
3.1.6	AC.L2-3.1.6	Access Control	1	Inherently manual (people, physical, or process evidence)
3.1.7	AC.L2-3.1.7	Access Control	1	Inherently manual (people, physical, or process evidence)
3.10.2	PE.L2-3.10.2	Physical Protection	1	Inherently manual (people, physical, or process evidence)
3.10.3	PE.L1-3.10.3	Physical Protection	1	Inherently manual (people, physical, or process evidence)
3.10.4	PE.L1-3.10.4	Physical Protection	1	Inherently manual (people, physical, or process evidence)
3.10.5	PE.L1-3.10.5	Physical Protection	1	Inherently manual (people, physical, or process evidence)
3.10.6	PE.L2-3.10.6	Physical Protection	1	Inherently manual (people, physical, or process evidence)
3.13.10	SC.L2-3.13.10	System and Communications Protection	1	No automated Siemserva check covers this control yet
3.13.12	SC.L2-3.13.12	System and Communications Protection	1	Inherently manual (people, physical, or process evidence)
3.13.13	SC.L2-3.13.13	System and Communications Protection	1	Inherently manual (people, physical, or process evidence)
3.13.14	SC.L2-3.13.14	System and Communications Protection	1	Inherently manual (people, physical, or process evidence)
3.13.7	SC.L2-3.13.7	System and Communications Protection	1	Inherently manual (people, physical, or process evidence)
3.2.3	AT.L2-3.2.3	Awareness and Training	1	No automated Siemserva check covers this control yet
3.3.3	AU.L2-3.3.3	Audit and Accountability	1	Inherently manual (people, physical, or process evidence)
3.3.7	AU.L2-3.3.7	Audit and Accountability	1	No automated Siemserva check covers this control yet
3.5.11	IA.L2-3.5.11	Identification and Authentication	1	No automated Siemserva check covers this control yet
3.6.3	IR.L2-3.6.3	Incident Response	1	No automated Siemserva check covers this control yet
3.7.3	MA.L2-3.7.3	Maintenance	1	Inherently manual (people, physical, or process evidence)
3.7.6	MA.L2-3.7.6	Maintenance	1	Inherently manual (people, physical, or process evidence)

Coverage by Control Family

Family	Passed	Attestation Required (Total)	Attestation With Scan Findings
Access Control	14	8	2
Audit and Accountability	6	3	0
Awareness and Training	0	3	0
Configuration Management	3	6	5
Identification and Authentication	9	2	0
Incident Response	2	1	0
Maintenance	0	6	0
Media Protection	4	5	2
Personnel Security	0	2	0
Physical Protection	0	6	0
Risk Assessment	0	3	2
Security Assessment	0	4	0
System and Communications Protection	4	12	0
System and Information Integrity	3	4	3

Attestation Priorities: Controls With Scan Findings (14)

These requirements need manual attestation and the scan surfaced findings in the checks that provide their evidence. Remediate the gaps or provide compensating evidence during assessment. Their SPRS weight is deducted from the estimate until then. Each control card ends with a "How to fix" guide per contributing check; expand a check for the goal, the technical plan, step-by-step instructions, and reference links.

AC.L1-3.1.1 NIST 3.1.1 · Access Control · -5 SPRS until attested

Requirement. Limit system access to authorized users, processes, and devices.

Why attestation is needed. 1 finding(s) across 1 entity map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Secret Expired. Application secret has expired. The application may lose access or fail authentication Risk: Expired app secrets break dependent services and can trigger emergency credential resets under pressure, increasing misconfiguration risk

How to fix / achieve this control.

Secret Expired

Goal. Remove expired secret; rotate to certificate-based credentials where possible

Steps.

UI: Entra admin center -> App registrations -> [App] -> Certificates & secrets.
Rotate expired or expiring credentials immediately; update dependent services with new credential.
Reissue non-expiring credentials with a finite lifetime; enforce app management policy to block creation of non-expiring secrets and certificates.
Reissue with shorter lifetime per policy; migrate secrets to certificate-based auth or managed identity; store in Key Vault.
Set expiry alerts; enable automated rotation; remove unused credentials.

References.

Affected entities (1).

ExpiredVendorIntegration High

AC.L1-3.1.2 NIST 3.1.2 · Access Control · -5 SPRS until attested

Requirement. Limit system access to the transactions and functions authorized users may execute.

Why attestation is needed. 1 finding(s) across 1 entity map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Secret Expired. Application secret has expired. The application may lose access or fail authentication Risk: Expired app secrets break dependent services and can trigger emergency credential resets under pressure, increasing misconfiguration risk

How to fix / achieve this control.

Secret Expired

Goal. Remove expired secret; rotate to certificate-based credentials where possible

Steps.

UI: Entra admin center -> App registrations -> [App] -> Certificates & secrets.
Rotate expired or expiring credentials immediately; update dependent services with new credential.
Reissue non-expiring credentials with a finite lifetime; enforce app management policy to block creation of non-expiring secrets and certificates.
Reissue with shorter lifetime per policy; migrate secrets to certificate-based auth or managed identity; store in Key Vault.
Set expiry alerts; enable automated rotation; remove unused credentials.

References.

Affected entities (1).

ExpiredVendorIntegration High

RA.L2-3.11.2 NIST 3.11.2 · Risk Assessment · -5 SPRS until attested

Requirement. Scan for vulnerabilities in systems and applications periodically and when new ones arise.

Why attestation is needed. 5 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Intune Device Vulnerability Kev. Device has one or more vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Risk: Defender for Endpoint's machinesVulnerabilities feed shows this device has at least one CVE present in CISA's KEV catalog. KEV CVEs have confirmed in-the-wild exploitation, so unpatched devices are at immediate risk. The affected products and CVE list are in the finding description.
Intune Device Vulnerable Software. Installed software carries known vulnerabilities in the Defender Vulnerability Management inventory. Risk: Defender's software inventory shows this product carries known vulnerabilities and is installed on exposed devices. While no public exploit or active alert is recorded yet, unpatched software is a common entry point and a frequent ingredient in attack chains.

How to fix / achieve this control.

Intune Device Vulnerability Kev

Goal. Patch the affected products immediately. The fix may be a Windows KB, a third-party application update, or a firmware update depending on the product. Cross-reference the CVE IDs in the description against vendor advisories. Treat these as the highest-priority devices in the patch queue.

Steps.

Read the finding text first: it names the affected device and the specific missing KB article or CVE ids Defender for Endpoint reported, so you know exactly what to install and why it matters (KEV means the vulnerability is being exploited in the wild).
Look the KB up in the Microsoft Update Guide (link below) if you want the full list of CVEs it fixes before deploying.
Deploy the update: in the Intune admin center go to Devices, Windows, Windows updates, Quality updates, and create an Expedite policy that names the missing KB. Target the affected device's group. For KEV findings do this immediately.
If the update should already have arrived through the normal ring, force a check-in: Devices, select the device, Sync. A stuck update agent is a common cause of one device lagging its ring.
Confirm the fix in the Microsoft Defender portal: Assets, Devices, select the device, Security recommendations. The missing-KB entry disappears after the device installs the update and reports back (allow up to 24 hours).
If the same device keeps appearing scan after scan, review which update ring it is assigned to: long quality-update deferrals or a paused ring leave devices exposed well past Patch Tuesday.

References.

Intune Device Vulnerable Software

Goal. Include the affected software in the regular update cycle and bring the exposed devices onto a non-vulnerable version. If a specific product is consistently behind, investigate why its update mechanism is failing.

Steps.

Open the Microsoft Defender portal -> Vulnerability management -> Recommendations (or Software inventory) and locate the item named in the finding.
Review the exposed devices and the recommended remediation: update to the recommended version, change a configuration, or uninstall the affected software.
For Microsoft products, deploy the update via Intune Update Rings or Autopatch. For third-party software, use a Win32 LOB app deployment or an external patch tool.
For recommendations with a public exploit or an active alert, treat the exposed devices as the highest priority in the patch queue.
After remediation, re-run the Siemserva audit and confirm the exposed-device count has dropped.

References.

Affected entities (3).

WS-PC-123 CriticalWS-PC-170 Criticalopenssl Low

SI.L1-3.14.1 NIST 3.14.1 · System and Information Integrity · -5 SPRS until attested

Requirement. Identify, report, and correct system flaws in a timely manner.

Why attestation is needed. 5 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Intune Device Vulnerability Kev. Device has one or more vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Risk: Defender for Endpoint's machinesVulnerabilities feed shows this device has at least one CVE present in CISA's KEV catalog. KEV CVEs have confirmed in-the-wild exploitation, so unpatched devices are at immediate risk. The affected products and CVE list are in the finding description.
Intune Device Vulnerable Software. Installed software carries known vulnerabilities in the Defender Vulnerability Management inventory. Risk: Defender's software inventory shows this product carries known vulnerabilities and is installed on exposed devices. While no public exploit or active alert is recorded yet, unpatched software is a common entry point and a frequent ingredient in attack chains.

How to fix / achieve this control.

Intune Device Vulnerability Kev

Steps.

Read the finding text first: it names the affected device and the specific missing KB article or CVE ids Defender for Endpoint reported, so you know exactly what to install and why it matters (KEV means the vulnerability is being exploited in the wild).
Look the KB up in the Microsoft Update Guide (link below) if you want the full list of CVEs it fixes before deploying.
Deploy the update: in the Intune admin center go to Devices, Windows, Windows updates, Quality updates, and create an Expedite policy that names the missing KB. Target the affected device's group. For KEV findings do this immediately.
If the update should already have arrived through the normal ring, force a check-in: Devices, select the device, Sync. A stuck update agent is a common cause of one device lagging its ring.
Confirm the fix in the Microsoft Defender portal: Assets, Devices, select the device, Security recommendations. The missing-KB entry disappears after the device installs the update and reports back (allow up to 24 hours).
If the same device keeps appearing scan after scan, review which update ring it is assigned to: long quality-update deferrals or a paused ring leave devices exposed well past Patch Tuesday.

References.

Intune Device Vulnerable Software

Steps.

Open the Microsoft Defender portal -> Vulnerability management -> Recommendations (or Software inventory) and locate the item named in the finding.
Review the exposed devices and the recommended remediation: update to the recommended version, change a configuration, or uninstall the affected software.
For Microsoft products, deploy the update via Intune Update Rings or Autopatch. For third-party software, use a Win32 LOB app deployment or an external patch tool.
For recommendations with a public exploit or an active alert, treat the exposed devices as the highest priority in the patch queue.
After remediation, re-run the Siemserva audit and confirm the exposed-device count has dropped.

References.

Affected entities (3).

WS-PC-123 CriticalWS-PC-170 Criticalopenssl Low

SI.L1-3.14.4 NIST 3.14.4 · System and Information Integrity · -5 SPRS until attested

Requirement. Update malicious code protection mechanisms when new releases are available.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Goal. Open the deployment in the Intune admin center (Devices -> Windows -> Windows updates -> Deployments), select the audience, and add updatable asset groups or individual Entra-joined devices. If exclusions cover the full member set, prune the exclusion list. Graph: GET /admin/windows/updates/deployments/{id}/audience/members and /audience/exclusions.

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Goal. Open the Intune admin center (Devices -> Windows -> Windows updates -> Enrollment) and run the enroll-devices flow against the affected group, or call POST /admin/windows/updates/updatableAssets/microsoft.graph.windowsUpdates.enrollAssetsById passing the group's member device ids. After enrollment, the group's deployment service members count should match the Entra group size.

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Goal. Reduce settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments. Edit the deployment in the Intune admin center or via PATCH on /admin/windows/updates/deployments/{id}.

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

CM.L2-3.4.2 NIST 3.4.2 · Configuration Management · -5 SPRS until attested

Requirement. Establish and enforce security configuration settings for IT products.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

CM.L2-3.4.6 NIST 3.4.6 · Configuration Management · -5 SPRS until attested

Requirement. Employ the principle of least functionality (essential capabilities only).

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

CM.L2-3.4.7 NIST 3.4.7 · Configuration Management · -5 SPRS until attested

Requirement. Restrict, disable, or prevent nonessential programs, ports, protocols, and services.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

CM.L2-3.4.8 NIST 3.4.8 · Configuration Management · -5 SPRS until attested

Requirement. Apply deny-by-exception or permit-by-exception policy for software execution.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

MP.L2-3.8.7 NIST 3.8.7 · Media Protection · -5 SPRS until attested

Requirement. Control the use of removable media on system components.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

SI.L1-3.14.5 NIST 3.14.5 · System and Information Integrity · -3 SPRS until attested

Requirement. Perform periodic and real-time scans of files from external sources.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

MP.L2-3.8.8 NIST 3.8.8 · Media Protection · -3 SPRS until attested

Requirement. Prohibit use of portable storage devices with no identifiable owner.

Why attestation is needed. 9 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Affected entities (3).

Expedite critical updates HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

RA.L2-3.11.3 NIST 3.11.3 · Risk Assessment · -1 SPRS until attested

Requirement. Remediate vulnerabilities in accordance with risk assessments.

Why attestation is needed. 5 finding(s) across 3 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Intune Device Vulnerability Kev. Device has one or more vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Risk: Defender for Endpoint's machinesVulnerabilities feed shows this device has at least one CVE present in CISA's KEV catalog. KEV CVEs have confirmed in-the-wild exploitation, so unpatched devices are at immediate risk. The affected products and CVE list are in the finding description.
Intune Device Vulnerable Software. Installed software carries known vulnerabilities in the Defender Vulnerability Management inventory. Risk: Defender's software inventory shows this product carries known vulnerabilities and is installed on exposed devices. While no public exploit or active alert is recorded yet, unpatched software is a common entry point and a frequent ingredient in attack chains.

How to fix / achieve this control.

Intune Device Vulnerability Kev

Steps.

Read the finding text first: it names the affected device and the specific missing KB article or CVE ids Defender for Endpoint reported, so you know exactly what to install and why it matters (KEV means the vulnerability is being exploited in the wild).
Look the KB up in the Microsoft Update Guide (link below) if you want the full list of CVEs it fixes before deploying.
Deploy the update: in the Intune admin center go to Devices, Windows, Windows updates, Quality updates, and create an Expedite policy that names the missing KB. Target the affected device's group. For KEV findings do this immediately.
If the update should already have arrived through the normal ring, force a check-in: Devices, select the device, Sync. A stuck update agent is a common cause of one device lagging its ring.
Confirm the fix in the Microsoft Defender portal: Assets, Devices, select the device, Security recommendations. The missing-KB entry disappears after the device installs the update and reports back (allow up to 24 hours).
If the same device keeps appearing scan after scan, review which update ring it is assigned to: long quality-update deferrals or a paused ring leave devices exposed well past Patch Tuesday.

References.

Intune Device Vulnerable Software

Steps.

Open the Microsoft Defender portal -> Vulnerability management -> Recommendations (or Software inventory) and locate the item named in the finding.
Review the exposed devices and the recommended remediation: update to the recommended version, change a configuration, or uninstall the affected software.
For Microsoft products, deploy the update via Intune Update Rings or Autopatch. For third-party software, use a Win32 LOB app deployment or an external patch tool.
For recommendations with a public exploit or an active alert, treat the exposed devices as the highest priority in the patch queue.
After remediation, re-run the Siemserva audit and confirm the exposed-device count has dropped.

References.

Affected entities (3).

WS-PC-123 CriticalWS-PC-170 Criticalopenssl Low

CM.L2-3.4.9 NIST 3.4.9 · Configuration Management · -1 SPRS until attested

Requirement. Control and monitor user-installed software.

Why attestation is needed. 10 finding(s) across 4 entities map to this control. Siemserva detected gaps in the checks that provide this control's evidence, so it cannot be verified automatically:

Autopatch Deployment No Members. Windows Autopatch deployment exists but its audience contains zero updatable assets, so no devices receive the patch. Risk: An Autopatch deployment whose audience is empty (no members, or all members excluded) is functionally identical to having no deployment at all. Operators see a 'green' deployment in the admin center while the targeted patch never reaches a single endpoint. This drift typically appears after a group is renamed or its membership rule no longer resolves.
Autopatch Updatable Asset Group Not Enrolled. Entra security group is registered as a Windows Autopatch updatable asset but its devices are not enrolled with the deployment service. Risk: Registering an Entra group as an updatableAssetGroup creates a reference but does not auto-sync the group's device members into the deployment service. Each device has to be explicitly enrolled via the Autopatch enrollment action. When the group has more devices in Entra than enrolled with the deployment service, any deployment targeting the group reaches fewer endpoints than the operator expects. With zero enrolled devices the deployment is functionally a no-op while the admin UI shows it as healthy. This is the most common cause of 'Autopatch is configured but nothing happens' tenant complaints.
Autopatch Deployment Reboot Delay Long. Windows Autopatch deployment forced-reboot deadline exceeds 5 days. Risk: A long forced-reboot deadline for an Autopatch deployment means devices that defer restart remain unpatched for days after the patch is delivered. Attackers exploit the gap between patch availability and installation; expedited security updates lose much of their value when the reboot deadline is loose.
Secret Expired. Application secret has expired. The application may lose access or fail authentication Risk: Expired app secrets break dependent services and can trigger emergency credential resets under pressure, increasing misconfiguration risk

How to fix / achieve this control.

Autopatch Deployment No Members

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Autopatch Updatable Asset Group Not Enrolled

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Enrollment to register devices as updatable assets.
UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments to create at least one active deployment.
Verify the scanning credential has WindowsUpdates.Read.All consented for the audit to read deployment service state.
Confirm the tenant is onboarded to the Windows Update for Business deployment service (Autopatch licensing/eligibility).
Graph: GET /admin/windows/updates/updatableAssets confirms device enrollment with the deployment service.
Graph: GET /admin/windows/updates/deployments?$expand=content($expand=catalogEntry) lists active deployments.
Graph: GET /admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') is the KB lookup capability check.

References.

Autopatch Deployment Reboot Delay Long

Steps.

UI: Intune admin center -> Devices -> Windows -> Windows updates -> Deployments. Open the deployment by id.
Inspect deployment.state.effectiveValue. Healthy values are scheduled, offering, complete. Investigate paused, faulted, cancelled.
For faulted state, read deployment.state.reasons in the Graph response for the underlying error and correct the root cause.
For paused state, decide whether to resume or replace the deployment.
Set settings.userExperience.daysUntilForcedReboot to 2 days or fewer for security and expedited deployments.
Graph: GET /admin/windows/updates/deployments/{id} returns the full state and settings payload.

References.

Secret Expired

Goal. Remove expired secret; rotate to certificate-based credentials where possible

Steps.

UI: Entra admin center -> App registrations -> [App] -> Certificates & secrets.
Rotate expired or expiring credentials immediately; update dependent services with new credential.
Reissue non-expiring credentials with a finite lifetime; enforce app management policy to block creation of non-expiring secrets and certificates.
Reissue with shorter lifetime per policy; migrate secrets to certificate-based auth or managed identity; store in Key Vault.
Set expiry alerts; enable automated rotation; remove unused credentials.

References.

Affected entities (4).

Expedite critical updates HighExpiredVendorIntegration HighAutopatch updatable asset group: Engineering MediumAutopatch updatable asset group: Finance Medium

Requirement Grades: All 110 Controls

Every NIST SP 800-171 Rev 2 requirement with its grade: Pass or Manual Attestation Required. Pass lists the evidence: the Siemserva checks (policies and settings inspected) that came back clean, or the Microsoft platform capability the control inherits. Manual Attestation Required means the control could not be verified automatically: the scan surfaced findings in its evidence checks (see Attestation Priorities above; SPRS weight deducts until remediated or attested), the control is inherently manual (people, physical, process), no automated check covers it yet, or a check ran but the data could not be determined (0 control(s), not counted as gaps). Provide evidence during assessment.

NIST	CMMC Practice	Requirement	Grade	Evidence / Basis
3.1.1	AC.L1-3.1.1	Limit system access to authorized users, processes, and devices.	Manual Attestation Required	1 scan finding(s) from: Secret Expired. Remediate or attest with evidence; see Attestation Priorities above.
3.1.2	AC.L1-3.1.2	Limit system access to the transactions and functions authorized users may execute.	Manual Attestation Required	1 scan finding(s) from: Secret Expired. Remediate or attest with evidence; see Attestation Priorities above.
3.1.3	AC.L2-3.1.3	Control the flow of CUI in accordance with approved authorizations.	Pass	Verified clean by 27 Siemserva checks, including: Share Point Storage Quota Used; High Share Point Storage Quota Used; One Drive Storage Quota Used; +24 more.
3.1.4	AC.L2-3.1.4	Separate the duties of individuals to reduce risk of collusion.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.1.5	AC.L2-3.1.5	Employ least privilege, including for security functions and privileged accounts.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.1.6	AC.L2-3.1.6	Use non-privileged accounts or roles when accessing non-security functions.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.1.7	AC.L2-3.1.7	Prevent non-privileged users from executing privileged functions; log such execution.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.1.8	AC.L2-3.1.8	Limit unsuccessful logon attempts.	Pass	Verified clean by 3 Siemserva check(s): Password Protection Lockout Threshold Too High; Password Protection Lockout Duration Too Short; Password Protection Not Enforced.
3.1.9	AC.L2-3.1.9	Provide privacy and security notices consistent with applicable CUI rules.	Pass	Verified clean by 3 Siemserva check(s): Tenant Branding Missing; Tenant Branding No Logo; Tenant Branding No Sign In Text.
3.1.10	AC.L2-3.1.10	Use session lock with pattern-hiding displays after inactivity.	Pass	Verified clean by 1 Siemserva check(s): Idle Lock Timeout Minutes.
3.1.11	AC.L2-3.1.11	Terminate a user session after a defined condition.	Pass	Verified clean by 51 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +48 more.
3.1.12	AC.L2-3.1.12	Monitor and control remote access sessions.	Pass	Verified clean by 53 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +50 more.
3.1.13	AC.L2-3.1.13	Use cryptographic mechanisms to protect confidentiality of remote access sessions.	Pass	Verified clean by 50 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +47 more.
3.1.14	AC.L2-3.1.14	Route remote access via managed access control points.	Pass	Verified clean by 50 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +47 more.
3.1.15	AC.L2-3.1.15	Authorize remote execution of privileged commands and access to security-relevant info.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.1.16	AC.L2-3.1.16	Authorize wireless access prior to allowing such connections.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.1.17	AC.L2-3.1.17	Protect wireless access using authentication and encryption.	Pass	Verified clean by 1 Siemserva check(s): Wifi Weak Security.
3.1.18	AC.L2-3.1.18	Control the connection of mobile devices.	Pass	Verified clean by 31 Siemserva checks, including: Is Enabled; Must Be Compliant; Not Registered; +28 more.
3.1.19	AC.L2-3.1.19	Encrypt CUI on mobile devices and mobile computing platforms.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.1.20	AC.L1-3.1.20	Verify and control/limit connections to and use of external systems.	Pass	Verified clean by 50 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +47 more.
3.1.21	AC.L2-3.1.21	Limit use of portable storage devices on external systems.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.1.22	AC.L1-3.1.22	Control CUI posted or processed on publicly accessible systems.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.2.1	AT.L2-3.2.1	Ensure managers, admins, and users are aware of security risks and policies.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.2.2	AT.L2-3.2.2	Ensure personnel are trained to carry out their assigned security duties.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.2.3	AT.L2-3.2.3	Provide security awareness training on recognizing and reporting insider threats.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.3.1	AU.L2-3.3.1	Create and retain audit logs sufficient to monitor, analyze, investigate, and report activity.	Pass	Verified clean by 46 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +43 more.
3.3.2	AU.L2-3.3.2	Ensure actions of individual users can be uniquely traced for accountability.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.3.3	AU.L2-3.3.3	Review and update logged events.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.3.4	AU.L2-3.3.4	Alert in the event of an audit logging process failure.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.3.5	AU.L2-3.3.5	Correlate audit record review, analysis, and reporting for investigation and response.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.3.6	AU.L2-3.3.6	Provide audit record reduction and report generation for on-demand analysis.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.3.7	AU.L2-3.3.7	Provide a capability to compare and synchronize to an authoritative time source.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.3.8	AU.L2-3.3.8	Protect audit information and audit logging tools from unauthorized access or modification.	Pass	Verified clean by 3 Siemserva check(s): Log Unavailable; Log No Records Returned; Permission Check Skipped.
3.3.9	AU.L2-3.3.9	Limit management of audit logging functionality to a subset of privileged users.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.4.1	CM.L2-3.4.1	Establish and maintain baseline configurations and inventories of systems.	Pass	Verified clean by 39 Siemserva checks, including: Organization On Premises Sync Times; Organization On Premises Last Password Sync Date Time Duration; Organization Verified Domains; +36 more.
3.4.2	CM.L2-3.4.2	Establish and enforce security configuration settings for IT products.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.4.3	CM.L2-3.4.3	Track, review, approve or disapprove, and log changes to systems.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.4.4	CM.L2-3.4.4	Analyze the security impact of changes prior to implementation.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.4.5	CM.L2-3.4.5	Define, document, approve, and enforce access restrictions associated with changes.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.4.6	CM.L2-3.4.6	Employ the principle of least functionality (essential capabilities only).	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.4.7	CM.L2-3.4.7	Restrict, disable, or prevent nonessential programs, ports, protocols, and services.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.4.8	CM.L2-3.4.8	Apply deny-by-exception or permit-by-exception policy for software execution.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.4.9	CM.L2-3.4.9	Control and monitor user-installed software.	Manual Attestation Required	10 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.5.1	IA.L1-3.5.1	Identify system users, processes acting on behalf of users, and devices.	Pass	Verified clean by 57 Siemserva checks, including: Unallowed Authentication Methods Enabled; Allowed Authentication Methods Disabled; Authentication Method Included User Target Registration Required; +54 more.
3.5.2	IA.L1-3.5.2	Authenticate identities of users, processes, or devices as a prerequisite to access.	Pass	Verified clean by 42 Siemserva checks, including: Unallowed Authentication Methods Enabled; Allowed Authentication Methods Disabled; Authentication Method Included User Target Registration Required; +39 more.
3.5.3	IA.L2-3.5.3	Use multifactor authentication for privileged accounts and network access to non-privileged accounts.	Pass	Verified clean by 150 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +147 more.
3.5.4	IA.L2-3.5.4	Employ replay-resistant authentication mechanisms for network account access.	Pass	Verified clean by 46 Siemserva checks, including: Unallowed Authentication Methods Enabled; Allowed Authentication Methods Disabled; Authentication Method Included User Target Registration Required; +43 more.
3.5.5	IA.L2-3.5.5	Prevent reuse of identifiers for a defined period.	Pass	Verified clean by 18 Siemserva checks, including: Member Of Directory Role; Public M 365 Group; Empty; +15 more.
3.5.6	IA.L2-3.5.6	Disable identifiers after a defined period of inactivity.	Pass	Verified clean by 22 Siemserva checks, including: Owned By Disabled User; Registered To Disabled User; Member Of Directory Role; +19 more.
3.5.7	IA.L2-3.5.7	Enforce a minimum password complexity and change of characters for new passwords.	Pass	Verified clean by 82 Siemserva checks, including: Missing User Optional License Match; Unallowed Authentication Methods Enabled; Allowed Authentication Methods Disabled; +79 more.
3.5.8	IA.L2-3.5.8	Prohibit password reuse for a specified number of generations.	Pass	Verified clean by 78 Siemserva checks, including: Missing User Optional License Match; Unallowed Authentication Methods Enabled; Allowed Authentication Methods Disabled; +75 more.
3.5.9	IA.L2-3.5.9	Allow temporary password use with an immediate change to a permanent password.	Pass	Verified clean by 3 Siemserva check(s): Temporary Access Pass Authentication Method In Use But Not Allowed By User; Temporary Access Pass Not Once Only; Temporary Access Pass Lifetime Too Long.
3.5.10	IA.L2-3.5.10	Store and transmit only cryptographically protected passwords.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.5.11	IA.L2-3.5.11	Obscure feedback of authentication information.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.6.1	IR.L2-3.6.1	Establish an operational incident-handling capability.	Pass	Verified clean by 1 Siemserva check(s): Ir Update Incident Response Plan And Process.
3.6.2	IR.L2-3.6.2	Track, document, and report incidents to designated officials and authorities.	Pass	Verified clean by 1 Siemserva check(s): Ir Update Incident Response Plan And Process.
3.6.3	IR.L2-3.6.3	Test the organizational incident response capability.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.7.1	MA.L2-3.7.1	Perform maintenance on organizational systems.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.7.2	MA.L2-3.7.2	Provide controls on the tools, techniques, mechanisms, and personnel for maintenance.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.7.3	MA.L2-3.7.3	Ensure equipment removed for off-site maintenance is sanitized of CUI.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.7.4	MA.L2-3.7.4	Check diagnostic and test media for malicious code before use.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.7.5	MA.L2-3.7.5	Require multifactor authentication for nonlocal maintenance sessions.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.7.6	MA.L2-3.7.6	Supervise maintenance activities of personnel without required access authorization.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.8.1	MP.L2-3.8.1	Protect (physically control and securely store) media containing CUI.	Pass	Verified clean by 27 Siemserva checks, including: Share Point Storage Quota Used; High Share Point Storage Quota Used; One Drive Storage Quota Used; +24 more.
3.8.2	MP.L2-3.8.2	Limit access to CUI on system media to authorized users.	Pass	Verified clean by 27 Siemserva checks, including: Share Point Storage Quota Used; High Share Point Storage Quota Used; One Drive Storage Quota Used; +24 more.
3.8.3	MP.L1-3.8.3	Sanitize or destroy media containing CUI before disposal or reuse.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.8.4	MP.L2-3.8.4	Mark media with necessary CUI markings and distribution limitations.	Pass	Verified clean by 11 Siemserva checks, including: None Configured; No Protection; Disabled; +8 more.
3.8.5	MP.L2-3.8.5	Control access to media and maintain accountability during transport.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.8.6	MP.L2-3.8.6	Use cryptographic mechanisms to protect CUI on digital media during transport.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.8.7	MP.L2-3.8.7	Control the use of removable media on system components.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.8.8	MP.L2-3.8.8	Prohibit use of portable storage devices with no identifiable owner.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.8.9	MP.L2-3.8.9	Protect the confidentiality of backup CUI at storage locations.	Pass	Verified clean by 6 Siemserva checks, including: No Labels Configured; Label No Behavior; Label Delete Only; +3 more.
3.9.1	PS.L2-3.9.1	Screen individuals prior to authorizing access to systems containing CUI.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.9.2	PS.L2-3.9.2	Protect CUI during and after personnel actions such as terminations and transfers.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.1	PE.L1-3.10.1	Limit physical access to systems, equipment, and operating environments.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.2	PE.L2-3.10.2	Protect and monitor the physical facility and support infrastructure.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.3	PE.L1-3.10.3	Escort visitors and monitor visitor activity.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.4	PE.L1-3.10.4	Maintain audit logs of physical access.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.5	PE.L1-3.10.5	Control and manage physical access devices.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.10.6	PE.L2-3.10.6	Enforce safeguarding measures for CUI at alternate work sites.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.11.1	RA.L2-3.11.1	Periodically assess risk from operating systems that process, store, or transmit CUI.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.11.2	RA.L2-3.11.2	Scan for vulnerabilities in systems and applications periodically and when new ones arise.	Manual Attestation Required	5 scan finding(s) from: Intune Device Vulnerability Kev; Intune Device Vulnerable Software. Remediate or attest with evidence; see Attestation Priorities above.
3.11.3	RA.L2-3.11.3	Remediate vulnerabilities in accordance with risk assessments.	Manual Attestation Required	5 scan finding(s) from: Intune Device Vulnerability Kev; Intune Device Vulnerable Software. Remediate or attest with evidence; see Attestation Priorities above.
3.12.1	CA.L2-3.12.1	Periodically assess security controls to determine effectiveness.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.12.2	CA.L2-3.12.2	Develop and implement plans of action (POA&M) to correct deficiencies.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.12.3	CA.L2-3.12.3	Monitor security controls on an ongoing basis to ensure continued effectiveness.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.12.4	CA.L2-3.12.4	Develop, document, and periodically update System Security Plans.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.1	SC.L1-3.13.1	Monitor, control, and protect communications at external and key internal boundaries.	Pass	Verified clean by 4 Siemserva checks, including: Lt Network Flow Logs Configured; Internet Facing Vm Protected By Nsg; Non Internet Facing Vm Protected By Nsg; +1 more.
3.13.2	SC.L2-3.13.2	Employ architectural designs and engineering principles that promote security.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.3	SC.L2-3.13.3	Separate user functionality from system management functionality.	Pass	Verified clean by 49 Siemserva checks, including: Service Principal Count In Privileged Roles; Service Principal Count In High Privileged Roles; Enforces Mfa For Admins; +46 more.
3.13.4	SC.L2-3.13.4	Prevent unauthorized and unintended information transfer via shared system resources.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.5	SC.L1-3.13.5	Implement subnetworks for publicly accessible system components.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.6	SC.L2-3.13.6	Deny network traffic by default and allow by exception.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.7	SC.L2-3.13.7	Prevent remote devices from split tunneling into the organization.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.8	SC.L2-3.13.8	Use cryptographic mechanisms to prevent disclosure of CUI during transmission.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.9	SC.L2-3.13.9	Terminate network connections at end of session or after inactivity.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.10	SC.L2-3.13.10	Establish and manage cryptographic keys for cryptography in organizational systems.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.13.11	SC.L2-3.13.11	Employ FIPS-validated cryptography to protect the confidentiality of CUI.	Manual Attestation Required	No automated Siemserva check covers this control yet.
3.13.12	SC.L2-3.13.12	Prohibit remote activation of collaborative computing devices and indicate use.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.13	SC.L2-3.13.13	Control and monitor the use of mobile code.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.14	SC.L2-3.13.14	Control and monitor the use of Voice over IP technologies.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.13.15	SC.L2-3.13.15	Protect the authenticity of communications sessions.	Pass	Verified clean by 50 Siemserva checks, including: Rule Applies In What If; Rule Does Not Apply In What If; Rule Applies In What If Read Only; +47 more.
3.13.16	SC.L2-3.13.16	Protect the confidentiality of CUI at rest.	Pass	Verified clean by 61 Siemserva checks, including: Share Point Storage Quota Used; High Share Point Storage Quota Used; One Drive Storage Quota Used; +58 more.
3.14.1	SI.L1-3.14.1	Identify, report, and correct system flaws in a timely manner.	Manual Attestation Required	5 scan finding(s) from: Intune Device Vulnerability Kev; Intune Device Vulnerable Software. Remediate or attest with evidence; see Attestation Priorities above.
3.14.2	SI.L1-3.14.2	Provide protection from malicious code at designated locations.	Manual Attestation Required	Inherently manual (people, physical, or process evidence).
3.14.3	SI.L2-3.14.3	Monitor system security alerts and advisories and take action in response.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.14.4	SI.L1-3.14.4	Update malicious code protection mechanisms when new releases are available.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.14.5	SI.L1-3.14.5	Perform periodic and real-time scans of files from external sources.	Manual Attestation Required	9 scan finding(s) from: Autopatch Deployment No Members; Autopatch Updatable Asset Group Not Enrolled; Autopatch Deployment Reboot Delay Long. Remediate or attest with evidence; see Attestation Priorities above.
3.14.6	SI.L2-3.14.6	Monitor systems and communications traffic to detect attacks and indicators.	Pass	Verified clean by 42 Siemserva checks, including: Failed Application Management Change; Application Activity; Audit Started; +39 more.
3.14.7	SI.L2-3.14.7	Identify unauthorized use of organizational systems.	Pass	Verified clean by 61 Siemserva checks, including: Failed Application Management Change; Application Activity; Risky User Not Protected; +58 more.