Supported changes and manual work

Every check in TenantVigil's catalogue, and what TenantVigil can do about it: make the change as a one-click fix, give the steps to make it yourself, or neither. For each one-click fix, the page gives the Microsoft call it sends, what Microsoft asks of the admin, what happens if the fix is interrupted, and how the change is checked afterwards.

The page is built from the same list the code uses. A one-click fix sends only the Microsoft Graph call listed here for its check: the same method, version and path, with a body checked against the shape that fix allows. Any unregistered configuration change is refused before it is sent, and so is a listed call whose body does not have that shape. The Native actions section names the other registered senders; apart from the audit-log search POST (`POST /security/auditLog/queries`) used for incident attribution, any other write is refused.

One-click fixes are offered only where TenantVigil has switched them on, and each one needs its own Microsoft consent from an admin of the tenant (see Permission model).

A Microsoft requirement reads "Not confirmed yet" when no Microsoft documentation page TenantVigil cites states it. Check Microsoft's documentation before you rely on it.

Directory-role assignments, app-consent grants and service principal credentials remain guided only and are never sent by TenantVigil. Their Microsoft API support does not make them native actions or grant TenantVigil the permissions they describe. Native identity, group, licence, device, messaging, Defender and restore actions are listed under Native actions.

Supported today: one app-only admin consent per customer tenant, plus the MSP's own sign-in. The customer approves TenantVigil's read access in that customer's tenant; the MSP sign-in controls access to the partner console. A second, optional admin consent is opt-in: where it is configured, Settings > Additional control checks offers it (/api/auth/consent/sharepoint). It is for a separate SharePoint app with the broader Sites.FullControl.All permission, which reads two SharePoint sharing settings (CISA-SPO-3.2 and CISA-SPO-3.3) that no read-only API exposes; it is never part of the standard consent.

GDAP, delegated admin and guest admin access are not supported and are guided only. Use the supported customer consent setup; these alternatives do not enable a TenantVigil connection.

Preview connection options: none.

Existing same-tenant safeguards still apply: Microsoft requests and consent remain scoped to the selected customer tenant, and an MSP sign-in does not grant another tenant's access. Connection consent is distinct from the separate delegated consent for each one-click fix, which remains as described in Permission model.

Each check has one class.

• Supported (19): TenantVigil can make this change as a one-click fix, with a generally available Microsoft Graph API.
• Preview (3): TenantVigil can make this change as a one-click fix, but only with a Microsoft Graph beta API, which Microsoft says is not supported for production use. The fix's preview warns the admin about this before the change.
• Guided (72): TenantVigil does not make this change. The check's page in the portal gives the steps to make it in Microsoft's admin centres or PowerShell.
• Unsupported (1): TenantVigil does not make this change and gives no steps for it.

These actions use registered native senders. Before a sender can call Microsoft for a customer, its callback URI must be registered and its Microsoft permission granted, and the customer may need to re-consent for a newly added permission. Until then the action stays unavailable for that customer.

Backup restore sessions need the backup permissions granted before use. Nothing below runs from assessment consent alone.

• op.user.create: POST https://graph.microsoft.com/v1.0/users. Microsoft permission: User.Create, User.Read.All.
• op.user.update: PATCH https://graph.microsoft.com/v1.0/users/{userId}. Microsoft permission: User.Read.All, User.ReadUpdate.All.
• op.user.password-reset: PATCH https://graph.microsoft.com/v1.0/users/{userId}. Microsoft permission: User-PasswordProfile.ReadWrite.All, User.Read.All.
• op.user.phone-method-remove: DELETE https://graph.microsoft.com/v1.0/users/{userId}/authentication/phoneMethods/{methodId}. Microsoft permission: UserAuthMethod-Phone.ReadWrite.All.
• op.user.block-sign-in: PATCH https://graph.microsoft.com/v1.0/users/{userId}. Microsoft permission: User.EnableDisableAccount.All, User.Read.All.
• op.user.unblock-sign-in: PATCH https://graph.microsoft.com/v1.0/users/{userId}. Microsoft permission: User.EnableDisableAccount.All, User.Read.All.
• op.group.member-add: POST https://graph.microsoft.com/v1.0/groups/{groupId}/members/$ref. Microsoft permission: GroupMember.ReadWrite.All.
• op.group.member-remove: DELETE https://graph.microsoft.com/v1.0/groups/{groupId}/members/{userId}/$ref. Microsoft permission: GroupMember.ReadWrite.All.
• op.licence.assign: POST https://graph.microsoft.com/v1.0/users/{userId}/assignLicense. Microsoft permission: LicenseAssignment.ReadWrite.All, User.Read.All.
• op.licence.remove: POST https://graph.microsoft.com/v1.0/users/{userId}/assignLicense. Microsoft permission: LicenseAssignment.ReadWrite.All, User.Read.All.
• op.group.owner-add: POST https://graph.microsoft.com/v1.0/groups/{groupId}/owners/$ref. Microsoft permission: Group.ReadWrite.All.
• op.group.owner-remove: DELETE https://graph.microsoft.com/v1.0/groups/{groupId}/owners/{userId}/$ref. Microsoft permission: Group.ReadWrite.All.
• op.group.guest-setting-create: POST https://graph.microsoft.com/v1.0/groups/{groupId}/settings. Microsoft permission: GroupSettings.ReadWrite.All.
• op.group.guest-setting-update: PATCH https://graph.microsoft.com/v1.0/groups/{groupId}/settings/{settingId}. Microsoft permission: GroupSettings.ReadWrite.All.
• op.device.sync: POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/syncDevice. Microsoft permission: DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.Read.All.
• op.device.restart: POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/rebootNow. Microsoft permission: DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.Read.All.
• op.device.retire: POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/retire. Microsoft permission: DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.Read.All.
• op.defender.isolate: POST Defender for Endpoint API /api/machines/{machineId}/isolate. Microsoft permission: Machine.Isolate, Machine.ReadWrite.
• op.defender.release: POST Defender for Endpoint API /api/machines/{machineId}/unisolate. Microsoft permission: Machine.Isolate, Machine.ReadWrite.
• op.mail.sendonbehalf-set: POST Exchange Admin API /Mailbox. Microsoft permission: Exchange.ManageV2.
• op.mail.calendar-permission-set: POST Exchange Admin API /MailboxFolderPermission. Microsoft permission: Exchange.ManageV2.
• op.mail.calendar-permission-remove: POST Exchange Admin API /MailboxFolderPermission. Microsoft permission: Exchange.ManageV2.
• op.backup.mailbox-restore-session-create: POST https://graph.microsoft.com/v1.0/solutions/backupRestore/exchangeRestoreSessions. Microsoft permission: BackupRestore-Restore.ReadWrite.All.
• op.backup.restore-session-activate: POST https://graph.microsoft.com/v1.0/solutions/backupRestore/restoreSessions/{sessionId}/activate. Microsoft permission: BackupRestore-Restore.ReadWrite.All.

TenantVigil keeps four kinds of change apart, and one never stands in for another: tenant policy (an organization setting, or a policy assigned to users), sharing administration (sharing and permissions on one site, file, team or mailbox), governance administration (a Microsoft Purview or Copilot governance setting or policy, such as audit, retention, sensitivity labels or data loss prevention), and content access (reading or changing files, mail or messages themselves, as eDiscovery and Communication Compliance do).

Every Exchange Online, SharePoint and OneDrive, and Teams check below is tenant policy (42 checks). TenantVigil neither administers sharing on single items nor reads or changes content to fix them. Where Microsoft lets a site or a user's policy differ from the organization setting, the check says so.

The checks CISA-DEFENDER-4.1, CISA-DEFENDER-6.1, CISA-DEFENDER-6.3 are governance administration. TenantVigil cannot read these settings, so they are checked by hand and earn no score.

For each of these checks the page gives the way Microsoft documents to make the change: the admin centre path and the PowerShell command, the role the admin needs, and whether it applies to the whole organization, to each policy, or to each item on its own. Where Microsoft has retired or replaced a setting, its notice is quoted.

How a change is made is a separate question from what TenantVigil can see. Microsoft Purview and Copilot governance, below, says what TenantVigil can and cannot read there.

Just before a fix sends its first change, TenantVigil records a receipt for it marked In progress, and afterwards updates that receipt with the outcome. Fix history shows the receipts.

If Microsoft's answer is unclear (a server error, or a timeout or lost connection after the change was sent), the receipt says Outcome unknown: Microsoft may have applied the change. TenantVigil never sends that change again by itself.

If TenantVigil stops before it records the outcome, the receipt reads In progress for 10 minutes and Outcome unknown after that. While it reads In progress, the same fix cannot be started again.

A change is sent only when it can finish, even at its slowest, before the request runs out of time. A fix that sends more than one change can end Partly applied, and its receipt names what was changed and what was not. Each one-click fix below says what running it again does.

Directory-role assignments, app-consent grants and service principal credentials are distinct capabilities. They never inherit generic user administration. Adding or removing a member of a role-assignable group grants or removes directory roles, so it is a directory-role assignment here, not standard group membership. Each needs separate review of the customer, target and scope; all remain guided and offer no action.

• Change directory role assignments: high-risk.directory-role-assignment. Guided only; no change is sent.
• Grant application consent: high-risk.app-consent-grant. Guided only; no change is sent.
• Change service principal credentials: high-risk.service-principal-credentials. Guided only; no change is sent.

TenantVigil offers this change through the registered native action op.user.create when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use Microsoft Entra admin centre > Users > New user after the customer approves the account and its source of authority.

• Class: Guided. Capability: identity.user-administration.
• Risk class: Standard. Registered native action: op.user.create.
• Target limit: This entry describes a workforce user. B2B guests use the invitation API, not this user-create operation.
• Target limit: Create synchronised identities on-premises; do not create a second cloud account for the same person.
• Create workforce user: POST https://graph.microsoft.com/v1.0/users. Preview: none.
• Licence for Create workforce user: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Create workforce user target limit: The UPN domain must be verified in the customer tenant. A federated UPN requires onPremisesImmutableId.
• Create workforce user target limit: Required fields include accountEnabled, displayName, mailNickname, passwordProfile and userPrincipalName for this workforce flow.
• Create workforce user, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: User.Create. Native role: Not confirmed yet. The endpoint page does not state a native role for this flow; not confirmed. Do not infer a role from a different endpoint. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Create workforce user, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: User.Create. Native role: Not confirmed yet. The endpoint page does not state a native role for this flow; not confirmed. Do not infer a role from a different endpoint. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Microsoft Learn for Create workforce user: https://learn.microsoft.com/en-us/graph/api/user-post-users?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil offers this change through the registered native actions op.user.block-sign-in, op.user.unblock-sign-in when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use Microsoft Entra admin centre > Users > the user > Properties to block sign-in, after checking the account's source and protected access paths.

• Class: Guided. Capability: identity.user-administration.
• Risk class: Standard. Registered native action: op.user.block-sign-in, op.user.unblock-sign-in.
• Target limit: For synchronised users, changes must be made on-premises. A UPN suffix alone does not establish federation.
• Target limit: Privileged directory-role holders, break-glass accounts and the last admin need separate customer review. Unknown protection evidence does not establish a safe target.
• Set accountEnabled to false: PATCH https://graph.microsoft.com/v1.0/users/{id}. Preview: none.
• Licence for Set accountEnabled to false: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Set accountEnabled to false target limit: This operation changes accountEnabled only. The source of authority and role hierarchy constrain the target; it does not revoke every existing session.
• Set accountEnabled to false, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: User.EnableDisableAccount.All + User.Read.All. Native role: Confirmed. The caller's role must outrank or cover the target's role under Microsoft's sensitive-action hierarchy. Privileged Authentication Administrator can update accountEnabled for all administrators. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Set accountEnabled to false, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: User.EnableDisableAccount.All + User.Read.All. Native role: Confirmed. The application must also hold a higher privileged administrator role appropriate to the target under Microsoft's sensitive-action hierarchy. Graph permissions alone are insufficient; confirm the role for the selected target. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Microsoft Learn for Set accountEnabled to false: https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil offers this change through the registered native action op.user.password-reset when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use the customer's Microsoft Entra admin centre password-reset flow after verifying the target and its password authority. Route synchronised accounts to the on-premises administrator.

• Class: Guided. Capability: identity.user-administration.
• Risk class: Standard. Registered native action: op.user.password-reset.
• Target limit: For synchronised users, changes must be made on-premises. A UPN suffix alone does not establish federation.
• Target limit: Privileged directory-role holders, break-glass accounts and the last admin need separate customer review. Unknown protection evidence does not establish a safe target.
• Target limit: A passwordProfile update and the authentication-method resetPassword action have different permissions and app-only support.
• Update passwordProfile: PATCH https://graph.microsoft.com/v1.0/users/{id}. Preview: none.
• Licence for Update passwordProfile: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Update passwordProfile target limit: passwordProfile cannot be used for federated users. Synchronised authority is a separate restriction; do not assume cloud password ownership.
• Update passwordProfile, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: User-PasswordProfile.ReadWrite.All. Native role: Confirmed. User Administrator can reset non-administrator passwords; Privileged Authentication Administrator is the least privileged role that can update passwordProfile for all administrators. The target-role hierarchy applies. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Update passwordProfile, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: User-PasswordProfile.ReadWrite.All. Native role: Confirmed. The application needs at least User Administrator in addition to its Graph permission. Confirm administrator-target limits separately before a manual change. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Microsoft Learn for Update passwordProfile: https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-1.0. Date read: 2026-10-17.
• Reset password authentication method: POST https://graph.microsoft.com/v1.0/users/{id}/authentication/methods/{methodId}/resetPassword. Preview: none.
• Licence for Reset password authentication method: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Reset password authentication method target limit: An administrator cannot reset their own password with this action. The method ID is 28c10230-6103-485e-b985-444c60001490.
• Reset password authentication method target limit: On-premises password writeback works only when configured; hybrid resets need newPassword. It is a long-running operation and is not available in China operated by 21Vianet.
• Reset password authentication method, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: UserAuthenticationMethod.ReadWrite.All. Native role: Confirmed. Authentication Administrator or Privileged Authentication Administrator; other password-reset roles are limited by the target-role hierarchy. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Reset password authentication method, App-only: unsupported. Microsoft does not support application access to this resetPassword action. Permissions required together: none; this flow is unsupported. Native role: Confirmed. No application role enables this flow: application access is unsupported. Requester: A customer administrator must choose a supported manual or delegated flow instead. Execution identity: No app-only execution identity is supported for this endpoint. Customer approval: Customer approval does not enable the unsupported app-only resetPassword flow. Resource scope: No application resource scope is supported for this resetPassword action.
• Microsoft Learn for Reset password authentication method: https://learn.microsoft.com/en-us/graph/api/authenticationmethod-resetpassword?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil offers this change through the registered native actions op.group.member-add, op.group.member-remove when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use Microsoft Entra admin centre > Groups > the group > Members. Check the source, group type and role-assignable setting before adding or removing a user.

• Class: Guided. Capability: identity.group-membership.
• Risk class: Standard. Registered native action: op.group.member-add, op.group.member-remove.
• Target limit: These permission bundles cover user members of ordinary security or Microsoft 365 groups. Other object types need their own endpoint-specific permissions.
• Target limit: Dynamic membership is rule-managed; synchronised group membership must be changed on-premises.
• Target limit: Role-assignable groups (isAssignableToRole true) are outside this standard capability: their membership grants directory roles, so adding or removing a member is listed under high-risk.directory-role-assignment and also needs RoleManagement.ReadWrite.Directory. Generic group administration does not cover it.
• Add a user member reference: POST https://graph.microsoft.com/v1.0/groups/{id}/members/$ref. Preview: none.
• Licence for Add a user member reference: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Add a user member reference target limit: Microsoft 365 groups accept user members; security groups allow more member types with different permissions. Multiple-member requests are limited to 20 members.
• Add a user member reference, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: GroupMember.ReadWrite.All. Native role: Confirmed. For groups that are not role-assignable: group owner, Groups Administrator, Directory Writers, Identity Governance Administrator or User Administrator; service-specific roles have group-type limits. Role-assignable groups are under the high-risk directory-role capability. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named customer-tenant group and member reference. Group owner and role boundaries still apply.
• Add a user member reference, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: GroupMember.ReadWrite.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named customer-tenant group and member reference. Group owner and role boundaries still apply.
• Microsoft Learn for Add a user member reference: https://learn.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0. Date read: 2026-10-17.
• Remove a user member reference: DELETE https://graph.microsoft.com/v1.0/groups/{id}/members/{memberId}/$ref. Preview: none.
• Licence for Remove a user member reference: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Remove a user member reference target limit: Keep /$ref on a manual Graph removal: omitting it can delete the directory object when the caller also has that object's write permission. Dynamic memberships cannot be removed this way.
• Remove a user member reference, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: GroupMember.ReadWrite.All. Native role: Confirmed. For groups that are not role-assignable: group owner, Groups Administrator, Directory Writers, Identity Governance Administrator or User Administrator; service-specific roles have group-type limits. Role-assignable groups are under the high-risk directory-role capability. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named customer-tenant group and member reference. Group owner and role boundaries still apply.
• Remove a user member reference, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: GroupMember.ReadWrite.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named customer-tenant group and member reference. Group owner and role boundaries still apply.
• Microsoft Learn for Remove a user member reference: https://learn.microsoft.com/en-us/graph/api/group-delete-members?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil offers this change through the registered native action op.user.phone-method-remove when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use Microsoft Entra admin centre > Users > the user > Authentication methods. Verify another sign-in method and protected-account access before removing a method.

• Class: Guided. Capability: identity.authentication-methods.
• Risk class: Standard. Registered native action: op.user.phone-method-remove.
• Target limit: Privileged directory-role holders, break-glass accounts and the last admin need separate customer review. Unknown protection evidence does not establish a safe target.
• Target limit: This catalogue confirms removal of another user's phone method only. It does not claim every method can be added, removed or registered by an administrator; other method operations remain unconfirmed and guided only.
• Target limit: Synchronised account source does not establish authority over every authentication method. Check the specific method in Microsoft.
• Delete another user's phone authentication method: DELETE https://graph.microsoft.com/v1.0/users/{id}/authentication/phoneMethods/{methodId}. Preview: none.
• Licence for Delete another user's phone authentication method: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Delete another user's phone authentication method target limit: For another user, the delegated permission is UserAuthMethod-Phone.ReadWrite.All; UserAuthenticationMethod.ReadWrite.All is the higher privileged alternative. The cited table's least privileged UserAuthMethod-Phone.ReadWrite covers only the signed-in user's own phone methods (https://learn.microsoft.com/en-us/graph/permissions-reference), so it does not allow this change.
• Delete another user's phone authentication method target limit: A default MFA phone number cannot be deleted until the user changes the default. An alternate mobile number depends on the primary mobile number. No other method endpoint is established here.
• Delete another user's phone authentication method, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: UserAuthMethod-Phone.ReadWrite.All. Native role: Confirmed. Authentication Administrator or Privileged Authentication Administrator for another user; target-role restrictions apply. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Delete another user's phone authentication method, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: UserAuthenticationMethod.ReadWrite.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Microsoft Learn for Delete another user's phone authentication method: https://learn.microsoft.com/en-us/graph/api/phoneauthenticationmethod-delete?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil does not make this change. The Microsoft APIs below describe manual administration requirements, not an action TenantVigil can send.

Use Microsoft Entra admin centre > Roles and administrators, or Groups > the group > Members for a role-assignable group. Obtain separate customer approval for the exact principal, role and scope; preserve emergency access and the last administrator.

• Class: Guided. Capability: high-risk.directory-role-assignment.
• Risk class: High risk. No action is offered.
• Target limit: Privileged directory-role holders, break-glass accounts and the last admin need separate customer review. Unknown protection evidence does not establish a safe target.
• Target limit: These are active directory-provider assignments. PIM eligibility, activation, schedules and entitlement-management roles are different operations; their requirements are not confirmed here.
• Target limit: Adding or removing a member of a role-assignable group (isAssignableToRole true) grants or removes the directory roles assigned to that group, so those group operations belong here, not to standard group membership.
• Create active directory role assignment: POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments. Preview: none.
• Licence for Create active directory role assignment: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Create active directory role assignment target limit: Approve principalId, roleDefinitionId and directoryScopeId explicitly. An administrative-unit or tenant-wide scope is not interchangeable.
• Create active directory role assignment, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: RoleManagement.ReadWrite.Directory. Native role: Confirmed. Privileged Role Administrator is the least privileged built-in role for the delegated directory provider, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the approved principal, directory role and directoryScopeId in the customer's tenant. This is not a generic user-admin permission.
• Create active directory role assignment, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: RoleManagement.ReadWrite.Directory. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the approved principal, directory role and directoryScopeId in the customer's tenant. This is not a generic user-admin permission.
• Microsoft Learn for Create active directory role assignment: https://learn.microsoft.com/en-us/graph/api/rbacapplication-post-roleassignments?view=graph-rest-1.0. Date read: 2026-10-17.
• Remove active directory role assignment: DELETE https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments/{id}. Preview: none.
• Licence for Remove active directory role assignment: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Remove active directory role assignment target limit: Remove only the approved assignment ID; check for loss of the acting administrator, break-glass or last-admin access before a manual removal.
• Remove active directory role assignment, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: RoleManagement.ReadWrite.Directory. Native role: Confirmed. Privileged Role Administrator is the least privileged built-in role for the delegated directory provider, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the approved principal, directory role and directoryScopeId in the customer's tenant. This is not a generic user-admin permission.
• Remove active directory role assignment, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: RoleManagement.ReadWrite.Directory. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the approved principal, directory role and directoryScopeId in the customer's tenant. This is not a generic user-admin permission.
• Microsoft Learn for Remove active directory role assignment: https://learn.microsoft.com/en-us/graph/api/unifiedroleassignment-delete?view=graph-rest-1.0. Date read: 2026-10-17.
• Add a member to a role-assignable group: POST https://graph.microsoft.com/v1.0/groups/{id}/members/$ref. Preview: none.
• Licence for Add a member to a role-assignable group: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Add a member to a role-assignable group target limit: Applies only when the group has isAssignableToRole true. The member gains every directory role assigned to the group; approve the group, the member and those roles explicitly.
• Add a member to a role-assignable group, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: GroupMember.ReadWrite.All + RoleManagement.ReadWrite.Directory. Native role: Confirmed. For a role-assignable group, Privileged Role Administrator is the least privileged supported role, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the approved role-assignable group (isAssignableToRole true) and member reference in the customer's tenant. The membership change grants or removes every directory role assigned to that group.
• Add a member to a role-assignable group, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: GroupMember.ReadWrite.All + RoleManagement.ReadWrite.Directory. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the approved role-assignable group (isAssignableToRole true) and member reference in the customer's tenant. The membership change grants or removes every directory role assigned to that group.
• Microsoft Learn for Add a member to a role-assignable group: https://learn.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0. Date read: 2026-10-17.
• Remove a member from a role-assignable group: DELETE https://graph.microsoft.com/v1.0/groups/{id}/members/{memberId}/$ref. Preview: none.
• Licence for Remove a member from a role-assignable group: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Remove a member from a role-assignable group target limit: Keep /$ref: omitting it can delete the member object when the caller also has that object's write permission. Check for loss of the acting administrator, break-glass or last-admin access before a manual removal.
• Remove a member from a role-assignable group, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: GroupMember.ReadWrite.All + RoleManagement.ReadWrite.Directory. Native role: Confirmed. For a role-assignable group, Privileged Role Administrator is the least privileged supported role, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the approved role-assignable group (isAssignableToRole true) and member reference in the customer's tenant. The membership change grants or removes every directory role assigned to that group.
• Remove a member from a role-assignable group, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: GroupMember.ReadWrite.All + RoleManagement.ReadWrite.Directory. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the approved role-assignable group (isAssignableToRole true) and member reference in the customer's tenant. The membership change grants or removes every directory role assigned to that group.
• Microsoft Learn for Remove a member from a role-assignable group: https://learn.microsoft.com/en-us/graph/api/group-delete-members?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil does not make this change. The Microsoft APIs below describe manual administration requirements, not an action TenantVigil can send.

Use Microsoft Entra admin centre > Enterprise applications > the application > Permissions. Have the customer review the publisher, resource, requested permissions and who receives access before granting consent.

• Class: Guided. Capability: high-risk.app-consent-grant.
• Risk class: High risk. No action is offered.
• Target limit: Delegated permission grants and application app-role assignments are different grants; neither inherits generic user administration.
• Target limit: This entry describes grant creation only. Grant update, revocation and consent policy changes are not confirmed by these endpoint records and remain guided only.
• Create delegated permission grant: POST https://graph.microsoft.com/v1.0/oauth2PermissionGrants. Preview: none.
• Licence for Create delegated permission grant: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Create delegated permission grant target limit: Principal grants cover one user; AllPrincipals grants cover all users and require administrator consent. The scope values must be permissions exposed by the named resource service principal.
• Create delegated permission grant, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: DelegatedPermissionGrant.ReadWrite.All. Native role: Confirmed. Supported delegated roles include Application Administrator, Cloud Application Administrator, Application Developer, Directory Writers, Privileged Role Administrator and User Administrator, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named client and resource service principals and approved permission scopes in the customer's tenant.
• Create delegated permission grant, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: DelegatedPermissionGrant.ReadWrite.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named client and resource service principals and approved permission scopes in the customer's tenant.
• Microsoft Learn for Create delegated permission grant: https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-post?view=graph-rest-1.0. Date read: 2026-10-17.
• Grant application app role: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments. Preview: none.
• Licence for Grant application app role: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Grant application app role target limit: Approve the client principalId, resourceId and appRoleId. A resource's application role is not a delegated scope; Microsoft recommends granting via the resource's appRoleAssignedTo relationship.
• Grant application app role, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: AppRoleAssignment.ReadWrite.All + Application.Read.All. Native role: Confirmed. Supported built-in roles: Directory Synchronization Accounts (only for the Microsoft Entra Connect and Microsoft Entra Cloud Sync services), Directory Writers, Hybrid Identity Administrator, Identity Governance Administrator, Privileged Role Administrator, User Administrator, Application Administrator, Cloud Application Administrator and Agent ID Administrator (for agent users only), or a suitable custom role. Privileged Role Administrator is the least privileged role supported for Microsoft Graph and Azure AD Graph app roles. The endpoint page does not say which other role covers which resource. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named client and resource service principals and approved permission scopes in the customer's tenant.
• Grant application app role, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: AppRoleAssignment.ReadWrite.All + Application.Read.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named client and resource service principals and approved permission scopes in the customer's tenant.
• Microsoft Learn for Grant application app role: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-approleassignments?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil does not make this change. The Microsoft APIs below describe manual administration requirements, not an action TenantVigil can send.

Use the customer's application credential management process in Microsoft Entra. Confirm whether the credential belongs to the application object or the enterprise application's service principal, stage a replacement and verify the workload before removing the old credential.

• Class: Guided. Capability: high-risk.service-principal-credentials.
• Risk class: High risk. No action is offered.
• Target limit: These endpoints change the service principal object, not its application registration. Do not substitute application-object credential endpoints.
• Target limit: A credential can give access as the workload and a removal can stop it. Separate customer approval and a rotation plan are required; generic user administration grants no such capability.
• Add service principal password: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/addPassword. Preview: none.
• Licence for Add service principal password: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Add service principal password target limit: The generated secret is returned only at creation; store it through the customer's approved secret process. TenantVigil never requests or displays it.
• Add service principal password, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: Application.ReadWrite.All. Native role: Confirmed. For owned applications: a member owner with default permissions or Application Developer. Otherwise: Application Administrator or Cloud Application Administrator, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Add service principal password, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: Application.ReadWrite.OwnedBy. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Microsoft Learn for Add service principal password: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-addpassword?view=graph-rest-1.0. Date read: 2026-10-17.
• Remove service principal password: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/removePassword. Preview: none.
• Licence for Remove service principal password: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Remove service principal password target limit: Requires the password credential's keyId. Verify that consumers use a working replacement before a manual removal.
• Remove service principal password, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: Application.ReadWrite.All. Native role: Confirmed. For owned applications: a member owner with default permissions or Application Developer. Otherwise: Application Administrator or Cloud Application Administrator, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Remove service principal password, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: Application.ReadWrite.OwnedBy. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Microsoft Learn for Remove service principal password: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-removepassword?view=graph-rest-1.0. Date read: 2026-10-17.
• Add service principal key: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/addKey. Preview: none.
• Licence for Add service principal key: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Add service principal key target limit: Requires proof of possession signed by an existing valid certificate. Without a valid certificate, this addKey action cannot bootstrap a new key; another update flow needs separate review.
• Add service principal key, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: Application.ReadWrite.All. Native role: Confirmed. For owned applications: a member owner with default permissions or Application Developer. Otherwise: Application Administrator or Cloud Application Administrator, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Add service principal key, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: Application.ReadWrite.OwnedBy. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Microsoft Learn for Add service principal key: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-addkey?view=graph-rest-1.0. Date read: 2026-10-17.
• Remove service principal key: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/removeKey. Preview: none.
• Licence for Remove service principal key: Not confirmed yet. The endpoint page does not establish a separate licence requirement; not confirmed. Check the customer's plan before a manual change.
• Remove service principal key target limit: Requires the keyId and proof of possession signed by an existing valid certificate. Check every workload using the key before manual removal.
• Remove service principal key, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: Application.ReadWrite.All. Native role: Confirmed. For owned applications: a member owner with default permissions or Application Developer. Otherwise: Application Administrator or Cloud Application Administrator, or a suitable custom role. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Remove service principal key, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: Application.ReadWrite.OwnedBy. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named service principal and credential in the customer's tenant; OwnedBy application permission is limited to owned applications.
• Microsoft Learn for Remove service principal key: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-removekey?view=graph-rest-1.0. Date read: 2026-10-17.

TenantVigil offers this change through the registered native actions op.licence.assign, op.licence.remove when the action's callback and Microsoft permissions are set up for the customer; until then, make it manually in Microsoft. The API requirements below describe the action and the manual change.

Use Microsoft 365 admin centre > Users > Active users > the user > Licences and apps. Confirm seats, usage location and service impact with the customer before changing assignments.

• Class: Guided. Capability: identity.licence-assignment.
• Risk class: Standard. Registered native action: op.licence.assign, op.licence.remove.
• Target limit: This is direct user licensing, not purchase, subscription changes or group-based licensing. Synchronised identity source does not by itself establish licence eligibility.
• Target limit: Privileged directory-role holders, break-glass accounts and the last admin need separate customer review. Unknown protection evidence does not establish a safe target.
• Assign or remove user licences: POST https://graph.microsoft.com/v1.0/users/{id}/assignLicense. Preview: none.
• Licence for Assign or remove user licences: Confirmed. The customer needs the subscription licences being assigned. The endpoint page does not establish an extra Entra premium licence for direct assignment; additional product and tenant eligibility remain unconfirmed.
• Assign or remove user licences target limit: Only a SKU the customer owns can be assigned. Verify available seats, usage location and service-plan dependencies in Microsoft; this catalogue does not establish tenant-specific eligibility.
• Assign or remove user licences target limit: addLicenses names SKU and disabled-plan IDs; removeLicenses names SKU IDs. Direct removal is not a change to a group-based assignment.
• Assign or remove user licences, Delegated: supported. Microsoft documents delegated work or school access for this endpoint; personal Microsoft accounts are not supported. Permissions required together: LicenseAssignment.ReadWrite.All. Native role: Confirmed. Directory Writers, License Administrator or User Administrator, or a custom role with microsoft.directory/users/assignLicense. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A signed-in administrator of the customer tenant using a delegated Microsoft Graph token. TenantVigil sends no write. Customer approval: The customer must approve the intended targets and delegated access in Microsoft, with an admin who can grant the required permissions. This catalogue requests no consent. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Assign or remove user licences, App-only: supported. Microsoft documents application access for this endpoint, without a signed-in execution user. Permissions required together: LicenseAssignment.ReadWrite.All. Native role: Not confirmed yet. A separate native role for the application identity is not stated on the endpoint page; not confirmed. A delegated user role is not an app-only role requirement. Requester: A customer-authorized administrator requests the manual change; the MSP's sign-in alone grants no customer authority. Execution identity: A service principal in the customer tenant using an app-only Microsoft Graph token. TenantVigil sends no write. Customer approval: A customer administrator must approve the intended targets and application permissions in Microsoft. TenantVigil's existing read consent does not grant these changes. Resource scope: Only the named user in the customer's tenant; never a user in the MSP's home tenant or another customer tenant.
• Microsoft Learn for Assign or remove user licences: https://learn.microsoft.com/en-us/graph/api/user-assignlicense?view=graph-rest-1.0. Date read: 2026-10-17.

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require MFA for administrator roles". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Block legacy authentication". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/identitySecurityDefaultsEnforcementPolicy.
• Microsoft Graph permission: Policy.ReadWrite.SecurityDefaults, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page names no Microsoft Entra role for this change.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/identitysecuritydefaultsenforcementpolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require a compliant or hybrid-joined device". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Microsoft Entra ID P2, as stated on https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require MFA for high-risk sign-ins". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Non-persistent browser sessions". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require MFA for all users". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/authorizationPolicy.
• Microsoft Graph permission: Policy.ReadWrite.Authorization, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Privileged Role Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/authorizationPolicy.
• Microsoft Graph permission: Policy.ReadWrite.Authorization, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Privileged Role Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/authorizationPolicy.
• Microsoft Graph permission: Policy.ReadWrite.Authorization, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Privileged Role Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/authorizationPolicy.
• Microsoft Graph permission: Policy.ReadWrite.Authorization, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Privileged Role Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Microsoft Entra ID P2, as stated on https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require MFA for medium and high sign-in risk". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Microsoft Entra ID P2, as stated on https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require password change for at-risk users". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. Microsoft lists Microsoft Entra ID P2 for its risk-based policies that require MFA or a password change; no cited Microsoft page states the licence for one that blocks.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Block high-risk users". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. Microsoft lists Microsoft Entra ID P2 for its risk-based policies that require MFA or a password change; no cited Microsoft page states the licence for one that blocks.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Block high-risk sign-ins". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Sms; PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Voice; PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Email.
• Microsoft Graph permission: Policy.ReadWrite.AuthenticationMethod, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing the authentication methods policy itself (Authentication Policy Administrator); a page for changing one method is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the policy first and turns off only the methods still on.
• Checked afterwards: TenantVigil reads the authentication methods policy again and confirms every targeted method is explicitly disabled. Missing methods, failed reads or enabled states remain outcome unknown.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/authenticationmethodspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require phishing-resistant MFA for privileged roles". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Require a managed device to register security info". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Supported.
• Microsoft call: POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies.
• Microsoft Graph permission: Policy.ReadWrite.ConditionalAccess, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: Not confirmed yet. The cited Microsoft page is for changing an existing policy (Security Administrator or Conditional Access Administrator); a page for creating one is not cited yet.
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: delete the policy TenantVigil created; its id is recorded on the fix's receipt.
• If it is interrupted after Microsoft accepted it: Running the fix again would create a second policy. First check Conditional Access for a policy named "TenantVigil — Block device code authentication flow". Microsoft may have applied this change, but its result is unresolved. Contact TenantVigil support. A person must reconcile the customer's Microsoft settings and the unresolved receipt.
• Checked afterwards: TenantVigil reads the created policy by Microsoft's returned id and verifies the planned body. Accepted, absent or mismatching evidence remains outcome unknown and blocks a new create until manual reconciliation. It remains in report-only mode, which Microsoft does not enforce, until an admin enables the policy.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/conditionalaccesspolicy-update

• Class: Preview.
• Microsoft call: PATCH https://graph.microsoft.com/beta/admin/sharepoint/settings.
• Microsoft Graph permission: SharePointTenantSettings.ReadWrite.All, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• To make the change yourself: Where: SharePoint admin center > Policies > Sharing > External sharing (SharePoint). PowerShell: Set-SPOTenant -SharingCapability (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: Each site has its own setting, which must be the same or more restrictive. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).

• Class: Preview.
• Microsoft call: PATCH https://graph.microsoft.com/beta/admin/sharepoint/settings.
• Microsoft Graph permission: SharePointTenantSettings.ReadWrite.All, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• To make the change yourself: Where: SharePoint admin center > Policies > Sharing > More external sharing settings > Allow guests to share items they don't own. PowerShell: Set-SPOTenant -PreventExternalUsersFromResharing $true (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: The organization setting covers all SharePoint sites and each user's OneDrive. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).

• Class: Preview.
• Microsoft call: PATCH https://graph.microsoft.com/beta/admin/sharepoint/settings.
• Microsoft Graph permission: SharePointTenantSettings.ReadWrite.All, delegated: the admin approves it in Microsoft for this one change.
• Microsoft role the admin needs: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• Licence: Not confirmed yet. No cited Microsoft page states the licence this change needs.
• Undo: the earlier value is recorded on the fix's receipt, so the setting can be set back to it.
• If it is interrupted after Microsoft accepted it: Running the fix again is safe: it reads the current setting first and sends the same value.
• Checked afterwards: TenantVigil reads the setting again and verifies that every planned property matches Microsoft's returned value. Missing, failed or mismatching reads remain outcome unknown; accepted work is never verified completion.
• Microsoft documentation cited: https://learn.microsoft.com/en-us/graph/api/sharepointsettings-update?view=graph-rest-beta
• To make the change yourself: Where: SharePoint admin center > Settings > Sync > Allow syncing only on computers joined to specific domains. PowerShell: Set-SPOTenantSyncClientRestriction -Enable -DomainGuids (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/set-spotenantsyncclientrestriction?view=sharepoint-ps. Applies to the whole organization: It covers SharePoint sites and OneDrive across the tenant (each geo in a multi-geo tenant), and only Active Directory domains, not Microsoft Entra domains. Source: https://learn.microsoft.com/en-us/sharepoint/allow-syncing-only-on-specific-domains (read on 2026-10-17).

Checks of Entra ID that TenantVigil guides but does not change.

• CIS-1.2.2: Break-glass emergency access accounts exist.
• CIS-1.2.1: Limit Global Administrator role assignments.
• CIS-1.3.1: MFA registration for all users.
• CISA-AAD-5.2: User app consent restricted to admin approval.
• CIS-1.6.1: App registrations have non-expired credentials.
• CIS-1.7.1: Named locations configured for Conditional Access.
• CISA-AAD-2.2: Admin notified when high-risk users detected.
• CISA-AAD-3.1: Phishing-resistant MFA enforced for all users.
• CISA-AAD-3.3: Microsoft Authenticator shows login context.
• CISA-AAD-3.4: Authentication Methods migration is complete.
• CISA-AAD-6.1: User passwords do not expire.
• CISA-AAD-7.2: Privileged users use fine-grained roles instead of Global Administrator.
• CISA-AAD-7.3: Privileged users use cloud-only accounts.
• CISA-AAD-8.3: Guest invitations restricted to approved inviters.

Checks of Exchange Online that TenantVigil guides but does not change.

• CIS-4.1.1: Transport rules do not forward email externally. Where: Exchange admin center > Mail flow > Rules. PowerShell: Set-TransportRule, to remove the redirect or copy to external recipients (Exchange Online PowerShell). Role: Organization Management, as stated on https://learn.microsoft.com/en-us/exchange/permissions-exo/feature-permissions. An Exchange Online role group; Microsoft maps the Exchange Administrator and Global Administrator roles to it (https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo). Applies to the whole organization: Every message that flows through the organization is checked against its enabled mail flow rules. Source: https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/manage-mail-flow-rules (read on 2026-10-17).
• CIS-4.2.1: Outbound auto-forwarding disabled on remote domains. Where: Exchange admin center > Mail flow > Remote domains (Automatic forwarding). PowerShell: Set-RemoteDomain -Identity Default -AutoForwardEnabled $false (Exchange Online PowerShell). Role: Organization Management, as stated on https://learn.microsoft.com/en-us/exchange/permissions-exo/feature-permissions. An Exchange Online role group; Microsoft maps the Exchange Administrator and Global Administrator roles to it (https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo). Applies to each item on its own: Each remote domain has its own setting. The Default remote domain applies to every domain (*) without an entry of its own, and a domain's own entry overrides it. Forwarding that admins set on mailboxes or in mail flow rules is not affected. Source: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/remote-domains/manage-remote-domains (read on 2026-10-17).
• CIS-4.3.1: Basic authentication disabled in authentication policies. Where: Microsoft 365 admin center > Settings > Org settings > Modern authentication (Microsoft says it uses authentication policies behind the scenes), or Exchange Online PowerShell, where Microsoft says all aspects of authentication policies are managed. PowerShell: New-AuthenticationPolicy, then Set-OrganizationConfig -DefaultAuthenticationPolicy (Exchange Online PowerShell). Role: Organization Management or Recipient Management, as stated on https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo. Exchange Online role groups; Microsoft lists authentication policies under their Recipient Policies role. Applies to each policy and the users it's assigned to: The default authentication policy applies to every user without one of their own, and a policy assigned to a user takes precedence. Changes take effect within 24 hours. Microsoft's notice: Microsoft has turned off basic authentication in all tenants, apart from SMTP AUTH in tenants that were using it, and has announced plans to retire basic authentication for SMTP AUTH too (https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online). Source: https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online (read on 2026-10-17).
• CIS-4.8.1: No auto-forwarding rules in remote domains. Where: Exchange admin center > Mail flow > Remote domains (Automatic forwarding). PowerShell: Set-RemoteDomain -AutoForwardEnabled $false, for each remote domain (Exchange Online PowerShell). Role: Organization Management, as stated on https://learn.microsoft.com/en-us/exchange/permissions-exo/feature-permissions. An Exchange Online role group; Microsoft maps the Exchange Administrator and Global Administrator roles to it (https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo). Applies to each item on its own: Each remote domain has its own setting. The Default remote domain applies to every domain (*) without an entry of its own, and a domain's own entry overrides it. Forwarding that admins set on mailboxes or in mail flow rules is not affected. Source: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/remote-domains/manage-remote-domains (read on 2026-10-17).
• CIS-4.4.1: DKIM signing configured for all domains. Where: Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, plus two CNAME records at the domain's DNS host. PowerShell: Set-DkimSigningConfig -Identity <domain> -Enabled $true (Exchange Online PowerShell). Role: Not confirmed yet. Microsoft's DKIM page names no role for this change. Applies to each item on its own: Each custom domain, and each subdomain that sends mail, needs its own DKIM configuration; mail from the *.onmicrosoft.com domain is signed automatically. Source: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure (read on 2026-10-17).
• CIS-4.5.1: Mailbox auditing enabled. Where: Exchange Online PowerShell (Microsoft documents no admin centre setting for this). PowerShell: Set-OrganizationConfig -AuditDisabled $false (Exchange Online PowerShell). Role: Not confirmed yet. Microsoft's auditing page names no role; the Exchange feature permissions list Organization configuration under Organization Management. Applies to the whole organization: Mailbox auditing on by default applies to the whole organization and overrides each mailbox's own on or off setting; a per-user bypass (Set-MailboxAuditBypassAssociation) still applies. Source: https://learn.microsoft.com/en-us/purview/audit-mailboxes (read on 2026-10-17).
• CIS-4.6.1: No transport rules whitelist specific domains. Where: Exchange admin center > Mail flow > Rules (Modify the message properties > set the spam confidence level (SCL)). PowerShell: Set-TransportRule -SetSCL (Exchange Online PowerShell). Role: Exchange Administrator or Global Administrator, as stated on https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/use-rules-to-set-scl. Applies to the whole organization: Every message that flows through the organization is checked against its enabled mail flow rules. Source: https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/use-rules-to-set-scl (read on 2026-10-17).
• CIS-4.7.1: Multiple verified domains configured. Where: Microsoft 365 admin center > Settings > Domains > Add domain. Role: Domain Name Administrator, as stated on https://learn.microsoft.com/en-us/microsoft-365/admin/setup/add-domain. Applies to the whole organization: Adding, changing or removing a domain affects the whole tenant. Source: https://learn.microsoft.com/en-us/microsoft-365/admin/setup/add-domain (read on 2026-10-17).
• CISA-EXO-2.2: SPF policy published for all domains. Where: The domain's DNS hosting service or registrar (a TXT record). Role: access to the domain's DNS hosting service, as stated on https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure. No Microsoft 365 role: Microsoft says there is no admin portal or PowerShell cmdlet in Microsoft 365 for this record. Applies to each item on its own: One SPF record per domain or subdomain; Microsoft sets the *.onmicrosoft.com record, which can't be changed. Source: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure (read on 2026-10-17).
• CISA-EXO-4.2: DMARC policy set to p=reject. Where: The domain's DNS hosting service or registrar (a TXT record at _dmarc). Role: access to the domain's DNS hosting service, as stated on https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure. No Microsoft 365 role: Microsoft says there is no admin portal or PowerShell cmdlet in Microsoft 365 for this record. Applies to each item on its own: Per domain; subdomains inherit the parent domain's DMARC record unless they publish their own. Source: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure (read on 2026-10-17).
• CISA-EXO-4.4: Agency point of contact for DMARC reports. Where: The domain's DNS hosting service or registrar (the rua and ruf tags of the TXT record at _dmarc). Role: access to the domain's DNS hosting service, as stated on https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure. No Microsoft 365 role: Microsoft says there is no admin portal or PowerShell cmdlet in Microsoft 365 for this record. Applies to each item on its own: Per domain; subdomains inherit the parent domain's DMARC record unless they publish their own. Microsoft 365 itself doesn't send DMARC forensic (ruf) reports. Source: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure (read on 2026-10-17).
• CISA-EXO-6.1: Contact folders not shared with all domains. Where: Exchange admin center > Organization > Sharing > Individual sharing. PowerShell: Set-SharingPolicy -Domains (Exchange Online PowerShell). Role: Not confirmed yet. Microsoft's sharing policy page names no role for this change. Applies to each policy and the users it's assigned to: Sharing policies are applied to mailboxes. A mailbox with no policy gets the default policy; disabling the default policy turns sharing off across the organization. Source: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-sharingpolicy?view=exchange-ps (read on 2026-10-17).
• CISA-EXO-6.2: Calendar details not shared with all domains. Where: Exchange admin center > Organization > Sharing > Individual sharing. PowerShell: Set-SharingPolicy -Domains (Exchange Online PowerShell). Role: Not confirmed yet. Microsoft's sharing policy page names no role for this change. Applies to each policy and the users it's assigned to: Sharing policies are applied to mailboxes. A mailbox with no policy gets the default policy; disabling the default policy turns sharing off across the organization. Source: https://learn.microsoft.com/en-us/exchange/sharing/sharing-policies/sharing-policies (read on 2026-10-17).
• CISA-EXO-7.1: External sender warnings implemented. Where: Exchange admin center > Mail flow > Rules (Prepend the subject of the message with). PowerShell: New-TransportRule -FromScope NotInOrganization -PrependSubject (Exchange Online PowerShell). Role: Organization Management, as stated on https://learn.microsoft.com/en-us/exchange/permissions-exo/feature-permissions. An Exchange Online role group; Microsoft maps the Exchange Administrator and Global Administrator roles to it (https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo). Applies to the whole organization: Every message that flows through the organization is checked against its enabled mail flow rules. Source: https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/manage-mail-flow-rules (read on 2026-10-17).
• CISA-EXO-13.1: Mailbox auditing enabled. Where: Exchange Online PowerShell (Microsoft documents no admin centre setting for this). PowerShell: Set-OrganizationConfig -AuditDisabled $false (Exchange Online PowerShell). Role: Not confirmed yet. Microsoft's auditing page names no role; the Exchange feature permissions list Organization configuration under Organization Management. Applies to the whole organization: Mailbox auditing on by default applies to the whole organization and overrides each mailbox's own on or off setting; a per-user bypass (Set-MailboxAuditBypassAssociation) still applies. Source: https://learn.microsoft.com/en-us/purview/audit-mailboxes (read on 2026-10-17).

Checks of Defender that TenantVigil guides but does not change.

• CIS-5.1.1: Anti-phishing policy enabled with impersonation protection.
• CIS-5.2.1: Safe Attachments enabled for Exchange Online.
• CIS-5.3.1: Safe Links enabled with URL scanning.
• CIS-5.1.2: Anti-phishing policy has appropriate threshold.
• CIS-5.2.2: Safe Attachments scans internal emails.
• CIS-5.3.2: Safe Links does not allow click-through to malicious URLs.
• CISA-DEFENDER-2.3: Domain impersonation protection for key partners.
• CISA-DEFENDER-3.1: Safe Attachments enabled for SharePoint, OneDrive, and Teams.
• CISA-DEFENDER-5.1: Required security alerts enabled in Defender.

Checks of Purview that TenantVigil guides but does not change.

• CISA-DEFENDER-1.1: Standard and Strict preset security policies enabled.
• CISA-DEFENDER-4.1: DLP policy configured to protect sensitive information. Where: Microsoft Purview portal > Data loss prevention > Policies > Create policy. PowerShell: New-DlpCompliancePolicy and New-DlpComplianceRule (Security & Compliance PowerShell). Role: Compliance Administrator or Compliance Data Administrator or Information Protection or Information Protection Admin or Security Administrator, as stated on https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy. Role groups; DLP Compliance Management is the narrower role. Applies to each policy and the users it's assigned to: Each policy covers the locations it names (Exchange, SharePoint, OneDrive, Teams, devices); a named location includes every instance of it unless one is excluded. Source: https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy (read on 2026-10-17).
• CISA-DEFENDER-6.1: Unified Audit Logging enabled. Where: Microsoft Purview portal > Audit > Start recording user and admin activity (turning it off is done in Exchange Online PowerShell). PowerShell: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true; check it with Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled (Exchange Online PowerShell). Role: Audit Logs (an Exchange Online role), as stated on https://learn.microsoft.com/en-us/purview/audit-log-enable-disable. The Compliance Management and Organization Management role groups in the Exchange admin center have it by default. Applies to the whole organization: Recording is on or off for the whole organization. Microsoft turns it on by default, but not for Microsoft 365 Business Basic, Business Standard and Business Premium, or for unmanaged tenants on enterprise trials. It can take up to 60 minutes to take effect. Source: https://learn.microsoft.com/en-us/purview/audit-log-enable-disable (read on 2026-10-17).
• CISA-DEFENDER-6.3: Audit logs retained for minimum required duration. Where: Microsoft Purview portal > Audit > Audit retention policies > Create audit retention policy. PowerShell: New-UnifiedAuditLogRetentionPolicy (Security & Compliance PowerShell); Get-UnifiedAuditLogRetentionPolicy doesn't return the organization's default policy. Role: Organization Configuration (a Microsoft Purview role), as stated on https://learn.microsoft.com/en-us/purview/audit-log-retention-policies. Applies to each policy and the users it's assigned to: Each policy covers the users, record types and activities it names (all users when none are named), with a priority from 1 to 10000; an organization can have up to 50. Source: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies (read on 2026-10-17).

Checks of SharePoint & OneDrive that TenantVigil guides but does not change.

• CIS-2.1.3: Anyone link expiration configured (≤30 days). Where: SharePoint admin center > Policies > Sharing > Advanced settings for Anyone links > Link expiration. PowerShell: Set-SPOTenant -RequireAnonymousLinksExpireInDays (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: A site can override it to be more or less restrictive, with Set-SPOSite -OverrideTenantAnonymousLinkExpirationPolicy $true (https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/set-sposite?view=sharepoint-ps). Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).
• CIS-2.1.4: Default sharing link type is 'Specific People'. Where: SharePoint admin center > Policies > Sharing > File and folder links > Specific people. PowerShell: Set-SPOTenant -DefaultSharingLinkType Direct (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: A site can set its own default. Microsoft's notice: Microsoft says -CoreDefaultShareLinkScope and -OneDriveDefaultShareLinkScope replace -DefaultSharingLinkType. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).
• CIS-2.1.5: Default sharing link permission is 'View'. Where: SharePoint Online Management Shell (Microsoft's current sharing page shows no organization-level setting for this). PowerShell: Set-SPOTenant -DefaultLinkPermission View (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: A site can set its own default. Microsoft's notice: Microsoft says -CoreDefaultShareLinkRole and -OneDriveDefaultShareLinkRole replace -DefaultLinkPermission. Source: https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/set-spotenant?view=sharepoint-ps (read on 2026-10-17).
• CISA-SPO-1.2: OneDrive external sharing restricted to existing guests or less. Where: SharePoint admin center > Policies > Sharing > External sharing (OneDrive). PowerShell: Set-SPOTenant -OneDriveSharingCapability (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: The OneDrive setting can be more restrictive than the SharePoint setting but not more permissive, and one user's OneDrive can be restricted further. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).
• CISA-SPO-1.3: External sharing restricted to approved domains. Where: SharePoint admin center > Policies > Sharing > More external sharing settings > Limit external sharing by domain > Allow only specific domains. PowerShell: Set-SPOTenant -SharingDomainRestrictionMode AllowList -SharingAllowedDomainList (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: A site's own list must be a subset of it, and the organization's list wins where they conflict. Source: https://learn.microsoft.com/en-us/sharepoint/restricted-domains-sharing (read on 2026-10-17).
• CISA-SPO-3.2: Anyone link permissions restricted to View only. Where: SharePoint admin center > Policies > Sharing > Advanced settings for Anyone links > Link permissions. PowerShell: Set-SPOTenant -FileAnonymousLinkType View -FolderAnonymousLinkType View (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: A site can set its own value. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).
• CISA-SPO-3.3: Email verification required for external sharing re-authentication. Where: SharePoint admin center > Policies > Sharing > More external sharing settings > People who use a verification code must reauthenticate after this many days. PowerShell: Set-SPOTenant -EmailAttestationRequired $true -EmailAttestationReAuthDays (SharePoint Online Management Shell). Role: SharePoint Administrator, as stated on https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off. Applies to the whole organization: When Microsoft Entra B2B collaboration is on, the Microsoft Entra setting is used instead. Source: https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off (read on 2026-10-17).

Checks of Teams that TenantVigil guides but does not change.

• CIS-7.1.1: External access in Teams properly controlled. Where: Teams admin center > Users > External access > Allow only specific external domains, or Block all external domains. PowerShell: Set-CsTenantFederationConfiguration -AllowedDomains (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: The organization setting applies to everyone, and per-user external access policies sit on top of it: a user can use external access only when both allow it. For external domains, the Allow or block external domains setting in a custom policy assigned to a user takes precedence over the organization setting; a user with no custom policy inherits the organization's domains. Source: https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat (read on 2026-10-17).
• CIS-7.1.2: Guest access in Teams is controlled. Where: Teams admin center > Users > Guest access. PowerShell: Set-CsTeamsClientConfiguration -AllowGuestUser (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: Guest access in Teams is an organization-wide setting; sensitivity labels can control it for individual teams. Source: https://learn.microsoft.com/en-us/microsoftteams/set-up-guests (read on 2026-10-17).
• CIS-7.2.1: External participants cannot request control of shared desktops. Where: Teams admin center > Meetings > Meeting policies > Content sharing > External participants can give or request control. PowerShell: Set-CsTeamsMeetingPolicy -AllowExternalParticipantGiveRequestControl $false (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. It applies to meetings organized by users with the policy. Source: https://learn.microsoft.com/en-us/microsoftteams/meeting-who-present-request-control (read on 2026-10-17).
• CISA-TEAMS-1.2: Anonymous users cannot start Teams meetings. Where: Teams admin center > Meetings > Meeting policies > Meeting join & lobby > Anonymous users and dial-in callers can start a meeting. PowerShell: Set-CsTeamsMeetingPolicy -AllowAnonymousUsersToStartMeeting $false (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. It applies per organizer. Source: https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby (read on 2026-10-17).
• CISA-TEAMS-1.3: Anonymous and dial-in users admitted via lobby. Where: Teams admin center > Meetings > Meeting policies > Meeting join & lobby > Who can bypass the lobby. PowerShell: Set-CsTeamsMeetingPolicy -AutoAdmittedUsers (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. Organizers can change this default in their meeting options; enforcing it needs a meeting template or sensitivity label, which needs Teams Premium. Source: https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby (read on 2026-10-17).
• CISA-TEAMS-1.4: Internal users admitted automatically without lobby. Where: Teams admin center > Meetings > Meeting policies > Meeting join & lobby > Who can bypass the lobby. PowerShell: Set-CsTeamsMeetingPolicy -AutoAdmittedUsers (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. Organizers can change this default in their meeting options; enforcing it needs a meeting template or sensitivity label, which needs Teams Premium. Source: https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby (read on 2026-10-17).
• CISA-TEAMS-1.5: Dial-in users cannot bypass the lobby. Where: Teams admin center > Meetings > Meeting policies > Meeting join & lobby > People dialing in can bypass the lobby. PowerShell: Set-CsTeamsMeetingPolicy -AllowPSTNUsersToBypassLobby $false (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. Organizers can change this default in their meeting options; enforcing it needs a meeting template or sensitivity label, which needs Teams Premium. Source: https://learn.microsoft.com/en-us/microsoftteams/who-can-bypass-meeting-lobby (read on 2026-10-17).
• CIS-7.2.2: Meeting recording appropriately restricted. Where: Teams admin center > Meetings > Meeting policies > Meeting recording. PowerShell: Set-CsTeamsMeetingPolicy -AllowCloudRecording (Teams PowerShell). Role: Teams Administrator or Teams Communications Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) meeting policy unless a custom policy is assigned to them or their group. It applies per organizer and per user; organizers with Teams Premium can choose who records in their meeting options. Source: https://learn.microsoft.com/en-us/microsoftteams/meeting-recording (read on 2026-10-17).
• CISA-TEAMS-1.7: Live events recording appropriately controlled. Where: Teams admin center > Meetings > Live events policies > Recording an event. PowerShell: Set-CsTeamsMeetingBroadcastPolicy -BroadcastRecordingMode (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global (Org-wide default) live events policy unless a custom policy is assigned to them. Microsoft's notice: Microsoft retired Teams live events on 30 June 2026; events scheduled before then are supported until 28 February 2027, and Microsoft recommends the Teams events experience instead. Source: https://learn.microsoft.com/en-us/microsoftteams/teams-live-events/what-are-teams-live-events (read on 2026-10-17).
• CISA-TEAMS-2.1: External domain access in Teams restricted. Where: Teams admin center > Users > External access > Allow only specific external domains. PowerShell: Set-CsTenantFederationConfiguration -AllowedDomains (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: The organization setting applies to everyone, and per-user external access policies sit on top of it: a user can use external access only when both allow it. For external domains, the Allow or block external domains setting in a custom policy assigned to a user takes precedence over the organization setting; a user with no custom policy inherits the organization's domains. Source: https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat (read on 2026-10-17).
• CISA-TEAMS-2.2: Unmanaged Teams users cannot initiate contact with internal users. Where: Teams admin center > Users > External access > External users with Teams accounts not managed by an organization can contact users in my organization. PowerShell: Set-CsTenantFederationConfiguration -AllowTeamsConsumerInbound $false (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: The organization setting applies to everyone, and per-user external access policies sit on top of it: a user can use external access only when both allow it. Source: https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat (read on 2026-10-17).
• CISA-TEAMS-2.3: Internal users cannot initiate contact with unmanaged Teams users. Where: Teams admin center > Users > External access > People in my organization can communicate with unmanaged Teams accounts. PowerShell: Set-CsTenantFederationConfiguration -AllowTeamsConsumer $false (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: The organization setting applies to everyone, and per-user external access policies sit on top of it: a user can use external access only when both allow it. Source: https://learn.microsoft.com/en-us/microsoftteams/trusted-organizations-external-meetings-chat (read on 2026-10-17).
• CIS-7.3.1: Teams email integration disabled. Where: Teams admin center > Teams > Teams settings > Email integration > Users can send emails to a channel email address. PowerShell: Set-CsTeamsClientConfiguration -AllowEmailIntoChannel $false (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to the whole organization: One Teams client configuration applies to the whole organization. Source: https://learn.microsoft.com/en-us/microsoftteams/settings-policies-reference (read on 2026-10-17).
• CISA-TEAMS-5.1: Only approved Microsoft apps allowed in Teams. Where: Teams admin center > Teams apps > Manage apps > each Microsoft app's availability (Users and groups > Edit availability). PowerShell: Update-M365TeamsApp, per app (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/manage-apps. Applies to the whole organization: Org-wide app settings apply to the whole organization; each app's availability (everyone, specific users or groups, or no one) is set per app. Microsoft's notice: Microsoft replaced app permission policies with app centric management and has been migrating tenants since April 2025; permission policies can't be used after the migration. Source: https://learn.microsoft.com/en-us/microsoftteams/app-centric-management (read on 2026-10-17).
• CISA-TEAMS-5.2: Only approved third-party apps allowed in Teams. Where: Teams admin center > Teams apps > Manage apps > Org-wide app settings (third-party apps), and each app's availability. PowerShell: Update-M365TeamsApp, per app (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/manage-apps. Applies to the whole organization: Org-wide app settings apply to the whole organization; each app's availability (everyone, specific users or groups, or no one) is set per app. Microsoft's notice: Microsoft replaced app permission policies with app centric management and has been migrating tenants since April 2025; permission policies can't be used after the migration. Source: https://learn.microsoft.com/en-us/microsoftteams/app-centric-management (read on 2026-10-17).
• CISA-TEAMS-5.3: Only approved custom apps allowed in Teams. Where: Teams admin center > Teams apps > Manage apps > Org-wide app settings (custom apps), and each app's availability. PowerShell: Update-M365TeamsApp, per app (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/manage-apps. Applies to the whole organization: Org-wide app settings apply to the whole organization; each app's availability (everyone, specific users or groups, or no one) is set per app. Microsoft's notice: Microsoft replaced app permission policies with app centric management and has been migrating tenants since April 2025; permission policies can't be used after the migration. Source: https://learn.microsoft.com/en-us/microsoftteams/app-centric-management (read on 2026-10-17).
• CIS-7.3.2: Giphy content rated appropriately in Teams. Where: Teams admin center > Messaging policies > Giphy content rating. PowerShell: Set-CsTeamsMessagingPolicy -GiphyRatingType Strict (Teams PowerShell). Role: Teams Administrator, as stated on https://learn.microsoft.com/en-us/microsoftteams/using-admin-roles. Applies to each policy and the users it's assigned to: Users get the Global messaging policy unless a custom policy is assigned to them; team and channel owners can also turn Giphy off for their team or channel. Source: https://learn.microsoft.com/en-us/microsoftteams/messaging-policies-in-teams (read on 2026-10-17).

Checks of Intune that TenantVigil guides but does not change.

• CIS-8.1.1: Device compliance policies exist.
• CIS-8.1.2: Compliance policies require password.
• CIS-8.1.3: Compliance policies require encryption.
• CIS-8.1.4: Compliance policies block jailbroken devices.
• CIS-8.2.1: Managed devices are compliant.
• CIS-8.2.2: Device encryption verified on managed devices.

TenantVigil does not make this change and gives no steps for it.

• META-SECURE-SCORE: Microsoft Secure Score. A score Microsoft reports, not a setting TenantVigil could change.

TenantVigil reads none of these settings. Microsoft Graph offers apps no read of most of them. Its generally available reads of sensitivity labels and eDiscovery cases need permissions TenantVigil does not have, and TenantVigil does not use Microsoft Graph's beta read of labels, which Microsoft does not support for production use. None of them counts towards a score or a framework, and a check that covers part of one is checked by hand. The portal's Compliance page lists the same areas under Governance coverage.

Content access, which TenantVigil takes no part in (Unsupported): eDiscovery cases, searches and holds; Communication Compliance. These search, export or review mail, files and messages, and the page only says how Microsoft documents them. For the other areas (Guided) it gives the way Microsoft documents to set them up.

• Audit recording (Guided, governance administration). What TenantVigil can see: Not supported. Microsoft Graph offers apps no read of whether audit recording is on. A search of the audit log cannot tell either: it returns nothing when recording is off, and also when nothing happened. Microsoft's own check is Get-AdminAuditLogConfig in Exchange Online PowerShell. Source: https://learn.microsoft.com/en-us/purview/audit-log-enable-disable. Checked by hand in CISA-DEFENDER-6.1. Where: Microsoft Purview portal > Audit > Start recording user and admin activity (turning it off is done in Exchange Online PowerShell). PowerShell: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true; check it with Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled (Exchange Online PowerShell). Role: Audit Logs (an Exchange Online role), as stated on https://learn.microsoft.com/en-us/purview/audit-log-enable-disable. The Compliance Management and Organization Management role groups in the Exchange admin center have it by default. Licence: Microsoft 365 E3 or Microsoft 365 Business Basic or Microsoft 365 Business Standard or Microsoft 365 Business Premium or Office 365 E3 or Office 365 E1, as stated on https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description. Audit (Standard); Microsoft's service description lists further plans. Applies to the whole organization: Recording is on or off for the whole organization. Microsoft turns it on by default, but not for Microsoft 365 Business Basic, Business Standard and Business Premium, or for unmanaged tenants on enterprise trials. It can take up to 60 minutes to take effect. Source: https://learn.microsoft.com/en-us/purview/audit-log-enable-disable (read on 2026-10-17).
• Audit log retention policies (Guided, governance administration). What TenantVigil can see: Not supported. Microsoft Graph offers apps no read of audit log retention policies. Source: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies. Checked by hand in CISA-DEFENDER-6.3. Where: Microsoft Purview portal > Audit > Audit retention policies > Create audit retention policy. PowerShell: New-UnifiedAuditLogRetentionPolicy (Security & Compliance PowerShell); Get-UnifiedAuditLogRetentionPolicy doesn't return the organization's default policy. Role: Organization Configuration (a Microsoft Purview role), as stated on https://learn.microsoft.com/en-us/purview/audit-log-retention-policies. Licence: Microsoft 365 E5 or Office 365 E5 or Microsoft Purview Suite or the E5 eDiscovery and Audit add-on, as stated on https://learn.microsoft.com/en-us/purview/audit-log-retention-policies. Audit (Premium), for keeping records longer than 180 days; keeping them for 10 years also needs the 10-year audit log retention add-on. Applies to each policy and the users it's assigned to: Each policy covers the users, record types and activities it names (all users when none are named), with a priority from 1 to 10000; an organization can have up to 50. Source: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies (read on 2026-10-17).
• Retention policies and retention labels (Guided, governance administration). What TenantVigil can see: Not supported. Microsoft Graph lets an app read retention labels only on behalf of a signed-in user, never as the app itself, and offers no read of retention policies. Source: https://learn.microsoft.com/en-us/graph/api/security-labelsroot-list-retentionlabel?view=graph-rest-1.0. Where: Microsoft Purview portal > Solutions > Data Lifecycle Management > Policies > Retention policies, and Data Lifecycle Management > Retention labels. PowerShell: New-RetentionCompliancePolicy and New-RetentionComplianceRule; New-ComplianceTag for retention labels (Security & Compliance PowerShell). Role: Compliance Administrator or Retention Management, as stated on https://learn.microsoft.com/en-us/purview/get-started-with-data-lifecycle-management. Microsoft recommends the Compliance Administrator role group; View-Only Retention Management is the read-only role. The admin needs no access to the content. Licence: Microsoft 365 E5 or Microsoft 365 E3 or Microsoft 365 Business Premium or Office 365 E5 or Office 365 E3, as stated on https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description. For organization-wide, location-wide or include and exclude retention policies; adaptive scopes need the E5 family. Applies to each policy and the users it's assigned to: A retention policy applies to whole locations, such as sites and mailboxes; a retention label applies to single items, such as a folder, document or email. A new policy can take up to seven days to apply. Source: https://learn.microsoft.com/en-us/purview/create-retention-policies (read on 2026-10-17).
• Sensitivity labels and label policies (Guided, governance administration). What TenantVigil can see: Not checked: needs a permission TenantVigil does not have (SensitivityLabels.Read.All). Microsoft Graph v1.0 lists a tenant's labels to apps only with SensitivityLabels.Read.All (or SensitivityLabel.Read), which TenantVigil does not have. With SensitivityLabels.Read.All it returns all of the tenant's labels. Source: https://learn.microsoft.com/en-us/graph/api/tenantdatasecurityandgovernance-list-sensitivitylabels?view=graph-rest-1.0. Where: Microsoft Purview portal > Solutions > Information Protection > Sensitivity labels, published to users in Information Protection > Publishing policies. PowerShell: New-Label and New-LabelPolicy (Security & Compliance PowerShell). Role: Information Protection or Information Protection Admins or Information Protection Analysts or Information Protection Investigators or Information Protection Readers or Sensitivity Label Administrator or Compliance Data Administrator or Compliance Administrator or Security Administrator, as stated on https://learn.microsoft.com/en-us/purview/get-started-with-sensitivity-labels. Role groups, in the order Microsoft lists them, apart from Sensitivity Label Administrator, a role Microsoft suggests adding to a new role group instead. Microsoft points to each role group's description for the roles it holds; Sensitivity Label Reader is the read-only role. Licence: Not confirmed yet. Microsoft's service description disagrees with itself: its text says sensitivity labelling needs Microsoft 365 E5 or Information Protection and Governance, and its table lists manual labelling for Microsoft 365 E3 and Business Premium too. Applies to each policy and the users it's assigned to: Labels reach users and groups through the label policies that publish them; a policy publishes to all users by default. Changes can take 24 hours to reach users. Source: https://learn.microsoft.com/en-us/purview/create-sensitivity-labels (read on 2026-10-17).
• Data loss prevention (DLP) policies (Guided, governance administration). What TenantVigil can see: Not supported. Microsoft Graph offers apps no read of DLP policies; its data security API works out what applies to one user, not the policies themselves. Source: https://learn.microsoft.com/en-us/graph/security-datasecurityandgovernance-overview. Checked by hand in CISA-DEFENDER-4.1. Where: Microsoft Purview portal > Data loss prevention > Policies > Create policy. PowerShell: New-DlpCompliancePolicy and New-DlpComplianceRule (Security & Compliance PowerShell). Role: Compliance Administrator or Compliance Data Administrator or Information Protection or Information Protection Admin or Security Administrator, as stated on https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy. Role groups; DLP Compliance Management is the narrower role. Licence: Microsoft 365 E5 or Microsoft 365 E3 or Microsoft 365 Business Premium or Office 365 E5 or Office 365 E3, as stated on https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description. For Exchange, SharePoint and OneDrive; DLP for Teams and devices needs the E5 family. Applies to each policy and the users it's assigned to: Each policy covers the locations it names (Exchange, SharePoint, OneDrive, Teams, devices); a named location includes every instance of it unless one is excluded. Source: https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy (read on 2026-10-17).
• eDiscovery cases, searches and holds (Unsupported, content access). What TenantVigil can see: Not supported. eDiscovery searches and exports mail, files and messages, which is content access. TenantVigil takes no part in it and does not read eDiscovery; Microsoft Graph offers apps a read of cases only with eDiscovery.Read.All, which TenantVigil does not have. Source: https://learn.microsoft.com/en-us/purview/edisc. Where: Microsoft Purview portal > eDiscovery (cases); access in Settings > Role groups. Role: eDiscovery Manager or eDiscovery Administrator, as stated on https://learn.microsoft.com/en-us/purview/edisc-permissions. An eDiscovery Manager sees only the cases they create; an eDiscovery Administrator sees every case. Licence: Microsoft 365 E3 or Office 365 E3, as stated on https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description. eDiscovery (Standard). Premium features need E5 or an E5 add-on, and Microsoft's pages disagree on whether the admin needs it too. Applies to each item on its own: Each case holds its own searches, holds and review sets; a hold applies to the content locations it names. Source: https://learn.microsoft.com/en-us/purview/edisc (read on 2026-10-17).
• Communication Compliance (Unsupported, content access). What TenantVigil can see: Not supported. Microsoft Graph offers apps no read of Communication Compliance policies, and reviewing what they capture means reading messages, which TenantVigil does not do. Source: https://learn.microsoft.com/en-us/purview/communication-compliance-configure. Where: Microsoft Purview portal > Communication Compliance > Policies > Create policy. Role: Communication Compliance Admins or Communication Compliance, as stated on https://learn.microsoft.com/en-us/purview/communication-compliance-permissions. Role groups. Microsoft says the Global Administrator and Compliance Administrator roles, and the Organization Management and Compliance Administrator role groups, have the same permissions as Communication Compliance Admins, and that PowerShell can't create or manage these policies. Licence: Microsoft 365 E5 or Office 365 E5 or Microsoft Purview Suite or Microsoft 365 E5 Insider Risk Management, as stated on https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description. Microsoft's service description lists further plans. Applies to each policy and the users it's assigned to: Each policy covers the users, groups or adaptive scopes and the channels it names, and reviewers read the messages it captures. Email can take about 24 hours to reach a policy. Source: https://learn.microsoft.com/en-us/purview/communication-compliance-configure (read on 2026-10-17).
• Copilot data access settings (Guided, governance administration). What TenantVigil can see: Not supported. Microsoft Graph offers apps no read of the Copilot data access settings or of Restricted Content Discovery. Source: https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-page. Where: Microsoft 365 admin center > Copilot > Settings > Data access; Restricted Content Discovery for one site in SharePoint admin center > Sites > Active sites > the site > Settings. PowerShell: Set-SPOSite -Identity <site-url> -RestrictContentOrgWideSearch $true, for Restricted Content Discovery (SharePoint Online Management Shell); Microsoft documents no PowerShell for the Copilot data access settings. Role: AI Administrator, as stated on https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-page. Global Reader can view the settings. Restricted Content Discovery needs SharePoint Administrator (https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery). Licence: Microsoft Copilot, as stated on https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-page. Microsoft shows these settings to organizations with a Copilot licence; Restricted Content Discovery also needs SharePoint Advanced Management. Applies to the whole organization: The Copilot settings are set for the organization (web search can also be set for users or groups); Restricted Content Discovery is set site by site, for SharePoint sites only, not OneDrive. Copilot only shows a user data they can already open. Microsoft's notice: Microsoft is retiring Restricted SharePoint Search: it has blocked new enablement since 31 July 2026 and points to Restricted Content Discovery instead (https://learn.microsoft.com/en-us/sharepoint/restricted-sharepoint-search). Source: https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-page (read on 2026-10-17).