August 6, 2026 SaaS Alerts release notes

New remediations

Four new SharePoint and OneDrive external sharing controls

Fortify now includes four new remediation actions designed to help organizations strengthen external sharing controls across SharePoint and OneDrive. All four are tenant-wide, cover SharePoint and OneDrive together, and support apply, undo, and nightly compliance validation. None of them require a new app permission: they reuse the SharePoint tenant-administration access granted in version 3.30.0, so no reconnect or re-consent is needed.

  • Require expiration for anonymous sharing links (fortify_anonymousSharingLinkExpiration)

    By default, SharePoint's "Anyone with the link" sharing links never expire; once shared, they keep working indefinitely, including for anyone the link is forwarded to. This action lets you set an expiration, configurable from 1 to 730 days, defaulting to 30 days (the CIS-recommended value). Shortening an existing expiration is retroactive, meaning links already issued will inherit the shorter limit. Lengthening it is not retroactive. Undo restores the tenant setting but cannot revive links that have already been clamped to a shorter expiration. Compliance is evaluated tenant-wide, so if a site administrator has overridden the tenant expiration policy at the site level, that site is not covered by this check.

  • Default sharing links to organization-only access (fortify_defaultSharingLinkOrganizationOnly)

    This action changes what SharePoint and OneDrive pre-select in the Share dialog, so a user who doesn't change the dropdown no longer creates an "Anyone with the link" link by accident. You can choose between "Only people in your organization" (the default) and "Specific people." The setting acts as a floor: if a tenant is already set to something stricter than what you request, it's treated as compliant and is never loosened. A site with its own default sharing link setting overrides this action, and such sites are not covered by the compliance check. Note that Microsoft applies this setting only to libraries using the modern experience; it does not affect Outlook on the web, Outlook 2016, or Office clients earlier than Office 2016.

  • Restrict anonymous sharing links to view-only access (fortify_anonymousLinkViewOnly)

    This action prevents an unauthenticated recipient of an anonymous link from modifying your content, for both files and folders. For folders, the permission is configurable as "View" (the default) or "View and upload"; the latter keeps the Request Files feature working. Files are always restricted to view, since edit is the only alternative for a file. Authenticated guest sharing ("Specific people" links) can still grant edit access, and because those recipients must sign in, their activity remains auditable. On a tenant where anonymous sharing is already turned off entirely, no anonymous link can exist, so the action reports compliant and leaves the tenant untouched. Unlike the two previous actions, this control has no per-site override; the tenant-level value is authoritative.

  • Default sharing links to view instead of edit permissions (fortify_defaultSharingLinkViewOnly)

    This action sets the permission that SharePoint and OneDrive pre-select when a user shares a file or folder, so the default grants view rather than edit access. It applies to organization and specific-people links as well as anonymous ones, so it remains effective even with external sharing turned off entirely. Applying this to a tenant that has never configured the setting cannot be undone, because SharePoint only accepts "view" or "edit" for this property and will not accept "not configured" back. The action will disclose this up front when applying, and will report accordingly if it happens. This action changes what the Share dialog pre-selects going forward; it does not alter links that already exist. A site with its own setting overrides this action and is not covered by the compliance check.

Enhancements

  • Improved policy snapshot reliability

    Microsoft began returning a new, undocumented property on Exchange Online, Defender, and Purview policy output, which caused snapshot creation and refresh to fail for those policy types. All affected policy models have been updated, and a check has been added so that a future addition of this kind from Microsoft is caught before it reaches you. Your backups were never affected by this issue. Separately, snapshot creation was failing for any organization whose Entra ID groups carried provisioning-error detail. This affected Intune device-configuration snapshots in practice, and was latent in roughly twenty other snapshot types. Both issues, along with a second instance of the Entra ID problem found in the Purview DLP snapshot path, have been fixed.

  • Enhanced compliance status reporting

    Previously, when a nightly compliance check ran but couldn't reach a verdict, for example, because Microsoft rejected the read, the action would either show a blank status on its first scan or silently continue displaying the previous scan's result as though it were current. Such actions now show "Compliance could not be determined. Fortify will retry on the next scan." The action's underlying compliance state, tags, and regression flag are left exactly as they were, so a failed check can never be mistaken for an actual change in your posture.

  • SharePoint and OneDrive action licensing awareness

    The four new SharePoint/OneDrive custom actions now declare a SharePoint license requirement. Organizations without a SharePoint plan will see "Not possible at current license" instead of having the action appear available and fail on every scan.

Fixes

  • Undoing the organization-only default sharing action on a previously unconfigured tenant

    Restoring an unconfigured default sharing link type was reporting success while actually leaving the tenant set to "Only people in your organization," because SharePoint resets this value rather than clearing it. The action no longer claims to restore a state it cannot reach; it now declines the undo and explains why, and the apply step now discloses up front that this particular change is not reversible. Organizations that applied this action before this release are automatically covered by the same safeguard.

  • Cloud gateway registration could fail permanently

    If registering a cloud gateway succeeded but the follow-up licensing step failed, an orphaned gateway record was left behind. Because registration rejects a duplicate gateway IP address, this blocked every subsequent retry until someone manually removed the record. Registration is now validated before anything is written, and rolled back automatically if the licensing step fails, so retries now work as expected. A related issue, where an organization ID present under two partners could be licensed against the wrong partner's connection, has also been resolved.

  • Portal changes could be overwritten by the nightly scan

    Organization settings edited in the portal, including the auto-upgrade toggle, could previously be silently overwritten if a nightly scan ran at the same time, and vice versa. Every update now writes only the fields it actually changed, preventing this conflict.

  • A disconnected organization could reappear

    An organization disconnected while its nightly scan was already in progress could have its connection record recreated by that scan. Disconnecting an organization now takes effect immediately and permanently.