To further reduce the attack surface of SharePoint Server and improve the overall security posture of SharePoint environments, legacy SharePoint workflow platforms will be disabled by default. This change affects both SharePoint 2010 and SharePoint 2013 workflows.
Organizations that still rely on SharePoint workflows can continue to use them by explicitly enabling workflow support on the required site collections. Workflow functionality can be enabled individually and only where business requirements dictate.
Timeline
- Starting with the September 2026 CU, SharePoint 2010 workflows are disabled by default for all site collections.
- Starting with the October 2026 CU, SharePoint 2013 workflows are disabled by default for all site collections.
Required Action
Administrators should review workflow usage across their SharePoint environment and identify site collections that still require SharePoint 2010 or SharePoint 2013 workflows.
Workflow support can be enabled proactively before installing the corresponding CU. If the August 2026 CU (or a later CU) is installed, the commands listed below can already be used to mark site collections that require workflow functionality. Performing this step before installing the September or October 2026 CU is strongly recommended to ensure that business-critical workflows remain operational after the update is applied.
Enable SP2010 workflows:
Enable SP2013 workflows:
Verifying Workflow Configuration
To identify site collections where workflow support has been explicitly enabled, use the following PowerShell commands:
List site collections with enabled SP2010 workflows:
List site collections with enabled SP2013 workflows:
Recommendation
As SharePoint 2010 and SharePoint 2013 workflows are legacy technologies, Microsoft recommends evaluating and migrating existing business processes to modern workflow and automation solutions where possible.
Limiting workflow enablement to only those site collections that require legacy workflow functionality helps minimize the attack surface while maintaining business continuity.
Permalink
Hello Stefan, I installed the August update yesterday, and the command I found is “Enable-SPWorkflow2013”.
Permalink
Hi Daniel,
yes, indeed! I fixed it.
Cheers,
Stefan
Permalink
I tried to publish the workflow, but I can’t
Permalink
Hi Stefan, calling SharePoint 2010 workflows “legacy” makes sense, as the new command names imply, but is it really also the case for SharePoint 2013 workflows? If so, what non-legacy version can we use for SharePoint on-prem workflows?
Permalink
There’s no on-premise workflow from microsoft any more. They want you to install an on-premise data gateway and use power automate.
Permalink
I recently tested a super straightforward installation of the gateway; Power Automate been able to connect to SharePoint Server sites and work on it; it seems to be the future of native SP2010 flows and SPWFM in my humble opinion.
SPWFM been a pain to maintain and even sometimes to install; building 2010/2013 flows is kinda laborious and the development environments start to retire; those technologies are really outdated; hard to use; they seems to be ready to vanish. Needless to say that latest SharePoint CU have been damaging 2010 flows a lot; most of environment I have to maintain, customers are not even aware they have these kind of legacy workflows; and most of the flows are not even working anymore.
In terms of cost; gateway is free to download; then comes the Power Automate licenses plans.
Permalink
If the intention is to keep part of the environment on-premises, this is certainly a good solution. However, we have decided to move the data and applications that remains on-premises to other systems because it is clear to us that SharePoint SE will also eventually reach end of life. The announcement regarding the discontinuation of OOS is already a clear signal of that.
Due to the large number of sites using InfoPath and workflows in our on-premises environment, we have been migrating for several years already and expect it will take a few more years to complete the process. Our primary focus initially was on migrating sites that used InfoPath and SharePoint 2010 workflows. Most of what still remains on-premises today consists of sites running SharePoint 2013 workflows.
It would simply require too much additional effort for us to temporarily redesign these workflows in Power Automate. Based on the information shared in this blog, we will continue with our current migration approach and hope that the 2013 workflows platform remain operational long enough for us to complete the migration.
Permalink
Hi Johan,
eventually – yes.
But Microsoft has committed support for SPSE at least till 2035 – which still a long time. See here:
https://learn.microsoft.com/en-us/lifecycle/additional-support-server-modern-lifecycle-policy
OOS is a separate unrelated product owned by a different team with its own support lifecycle and there is no relationship between end of support for OOS and end of support of SPSE.
Cheers,
Stefan
Permalink
Hi Stefan,
For me, it’s also not entirely clear.
In 2023, Microsoft still introduced the SharePoint Workflow Manager, with long-term support for the workflow 2013 platform beyond 2026.
https://techcommunity.microsoft.com/blog/spblog/announcing-the-release-of-sharepoint-workflow-manager-for-sharepoint-server/3744881
On this forum, it was stated that from 2026 onward, you could continue by creating workflows via Visual Studio. Is this information still accurate? There must indeed be a way to continue using flows in some form that remain supported.
Thanks,
Johan
Permalink
Hi Johan,
yes it is.
Cheers,
Stefan
Permalink
Hi Samson,
SharePoint 2013 workflows will stay – but investment will be limited. e.g.:
– SharePoint Designer is no longer supported which makes workflow creation and maintenance more complicated
– SharePoint Workflow development in Visual Studio is deprecated and will be removed in a future release.
Cheers,
Stefan
Permalink
Where are these powershell commandlets found?
PS C:\Program Files\Workflow Manager\1.0> Get-SPLegacyWorkflowEnabledSites
Get-SPLegacyWorkflowEnabledSites : The term ‘Get-SPLegacyWorkflowEnabledSites’ is not recognized as the name of a
cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify…….
PS C:\Windows\system32> Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
PS C:\Windows\system32> Get-SPLegacyWorkflowEnabledSites
get-splegacyworkflowenabledsites : The term ‘get-splegacyworkflowenabledsites’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
Permalink
Hi Michael,
you will find them on SharePoint Server Subscription Edition Servers with August 2026 CU installed in the SharePoint Management Shell.
Cheers,
Stefan
Permalink
I have a script that will find all sites in all WebApps and turn on these on (excluding Central Admin), it can run with a WhatIf first, so you can see what it will do without it actually changing anything. You can also run it against individual WebApps if desired. It outputs the results to a .csv showing all successes and failures. What is the best way to share this if people are interested in it?
Permalink
HI Stefan,
It looks MS is going to continue releasing CUs for SP 2016 or September CU is the last one?
Please confirm.
Permalink
Hi Aditya,
afaik, August 2026 CU was the last one.
Cheers,
Stefan
Permalink
Hi Stefan,
Will August 2026 CU also be the last one for SP2019? Also, I wanted to confirm that it will not disable workflows in SP2019?
Thanks,
Winston
Permalink
Hi Winston,
the current plan that has been communicated is that the final CU is August CU.
In case this plan changes in the future and for some reason another fix is released this might be disabled as well.
Cheers,
Stefan
Permalink
Will Sharepoint Designer continue to work for the 2010/2013 workflows?
I realize it won’t be supported but is that tool going to break as well?
Permalink
Hi Tyler,
for now – yes. But no guarantee that there will not be a breaking change going forward.
Cheers,
Stefan
Permalink
Hi Stefan,
I note that the relevant ‘enable’ commands are available from the August 2026 patch but will there be a cut off point where we are no longer allowed to do this or will the workflows always work so long as we have run the enable command? I need to advise internally on our options and potential timelines.
As you mentioned above, SharePoint Designer may break in future security updates so I wanted to know if there’s a timeline that we need to be wary of for legacy workflows too?
Thanks,
Chris
Permalink
This is the timeline. It’s dead and will be disabled by default in the upcoming CU. For everything else: good luck.
Permalink
Yes, it is dead but my point is: how long will we be able to use Enable-SPLegacyWorkflow http://site-collection-url and Enable-SPWorkflow2013 http://site-collection-url?
Is it something that’s a sticking plaster to give people more time to migrate or could we, for instance, still rely on it by end of 2026?
Permalink
Hi Chris,
for SP2013 this should be working going forward. No end date for support for SP2013 workflows in SPSE has been announced.
For SP2010 workflows this is a different story. They are already unsupported.
I did not receive any information on specific plans to disable it – but my personal guess would be that it will be disabled as soon as the next critical security issue is identified in this functionality.
With other words: don’t bet on this going forward.
Cheers,
Stefan
Permalink
Hi Stefan
Would it make sense to migrate the WF 2010 to WF 2013 to ensure that the WF remains operational in the medium term?
Thank you for your quick feedback.
Permalink
Hi Werner, yes – this is one of the recommended migration paths.
Permalink
Hi Stefan and thanx for an yet another informative blog post. Will workflows be disabled on existing site collection as well with existing workflows or is it only when creating a new site collection?
Permalink
Hi Jonas,
it will be disabled on all Site collections including existing if not allowed before or after installing September CU.
Cheers,
Stefan
Permalink
– SharePoint Workflow development in Visual Studio is deprecated and will be removed in a future release.
wow that’s new to me – are there any addional informations available ?
Permalink
VS 2022 is following the classic support lifecycle – means it is supported till 2032. VS 2026 and later follow the modern support livecycle which means it is supported much shorter.
The current recommendation is to us VS 2022 for workflow development.
Permalink
Hi Stefan, obviously we will test this, but I assume those cmdlets set a $true or similar at the site level.
Scenario 1:
– Currently migrating from SP2019
– In SP2019, upgrade to Aug 2026 CU
– Run cmdlets to enable SP10/SP13 WFs on sites.
– Run DB migration to SP Subscription Edition (which is also at at least Aug 2026 CU)
– Assume those $true flags will migrate to SPSE or will we have to rerun the cmdlets in SPSE post migration?
Scenario 2:
– It is the FUTURE! we are in 2027 and at, for example, Feb 2027 CU in Subscription
– Customer creates new site collection
– We are no longer able to run the cmdlets post September CU? Customer cannot utilize a SP13 Engine WF on the newly created site collection?
Thank you
Permalink
The CmdLets can of course also be executed after September CU. New site collections are not treated differently from older ones.
Regarding the upgrade from 2019 to subscription edition: this might require to set execute the command again after attaching to the SPSE farm.
Cheers,
Stefan
Permalink
I am still getting “Unauthorized” from SPWFM workflows after installing the August 2026 SharePoint CU. both on SP Server 2016 and SPSE
Permalink
Please try to apply update https://support.microsoft.com/en-us/servicing/office/hotfix/august/5002864 for SharePoint Workflow Manager (KB5002864)
Permalink
Try to apply August 11, 2026, update for SharePoint Workflow Manager (KB5002864) https://support.microsoft.com/en-us/servicing/office/hotfix/august/5002864
Permalink
I have installed latest sharePoint workflow manager update (KB5002864). I am still getting the same error on the workflow HTTP unauthorized
Permalink
Hi Ax,
Whether the update is in accordance with the recommendation procedures for the existing farm?
Permalink
Hey Stefan,
May I ask why this disablement is being done? Is there something we should worry about as users when it comes to these workflows?
Permalink
Hi Omar, to reduce the attack surface of SharePoint. The smaller the number of enabled features in a site collection the smaller the attack surface and the smaller the chance that a malicious actor can identify and exploit new security vulnerabilities.
Cheers,
Stefan
Permalink
Hey Stefan
Thank you for the quick reply and for updating the blog
Just confirming, does this also affect SP16?
If so, have workflows been disabled there in the August patch? We are getting reports of workflows no longer being functional after we applied that patch.
Permalink
Hi Omar,
this applies to products where a September 2026 CU will be released.
August CU did not disable workflows.
Cheers,
Stefan
Permalink
Hi Stefan, what is the rollback command of this cmdlet.
Enable-SPLegacyWorkflow http://site-collection-url
I would need to Disable SPLegacyWorkflow as well. Kindly confirm, if it is doable.
Permalink
The command to disable is “Disable-SPLegacyWorkflow”.
You can get a list of all relevant commands using.
Get-Command SPLegacyWorkflow
Permalink
We apparently still have a few list retention policies linked to SharePoint 2010 workflows. Unfortunately, this functionality does not support SharePoint 2013 workflows.
We are currently in the process of converting these to windows scheduled tasks.
Hopefully, the September CU will not break this functionality (even if the site is enabled for WF2010), allowing us to continue using it for a little while longer.
Permalink
This might’ve been address before in another post. But, is there a path forward past SP2013 Workflows for those of us who have farms in closed networks (i.e. no internet access)? Let’s say a gateway is also not in the cards.
Permalink
Hi Rod,
in this case 2013 workflows can be used.
Alternatively 3rd party workflow solutions would be an option if 2013 workflows do not fulfill your needs.
Cheers,
Stefan
Permalink
Hi Stefan,
we have been waiting for more information about the disabling of SharePoint 2013 workflows, but your post is still our only source. Will there be an announcement on the Microsoft support website? Can you also confirm that SharePoint Workflows 2013 will be supported further on and that the workflow environment will continue to receive security updates? As we followed the recommendation to limit the number of workflows to only the critical ones, some will remain in place and need to be used safely.
Best regards,
Nico
Permalink
Hi Nico,
Yes. 2013 workflows will be supported going forward and will continue to receive security updates.
Cheers,
Stefan
Permalink
Does this command need running on all new sites we create going forward? We use a site provisioning engine and if we need to run this on each new site, i will need to change the script to do this after it is built.
Permalink
Hi Matt,
not for each site – but for each new site collection.
Cheers,
Stefan
Permalink
Thank you
Permalink
Hi Stefan,
We are seeing something very similar during a customer DR test migrating from SharePoint 2019 to SPSE.
The SPSE farm is on the August 2026 CU, build 16.0.19725.20522, and both SharePoint Workflow Manager and the SPWFM Client are also 16.0.19725.20522.
The migrated SharePoint 2013 workflow subscription is present in SPSE and the workflow can be submitted to Workflow Manager successfully. The workflow instance actually starts and remains healthy in SPWFM.
The failure occurs when Workflow Manager calls back into SharePoint through REST. SPSE returns:
HTTP 401
x-ms-diagnostics: 3001000
category=”invalid_client”
We have already validated/repaired the normal migration items including Register-SPWorkflowService -Force, SharePoint/WFM realm alignment, STS NameIdentifier, WFM scope metadata, trusted Workflow issuer/certificate, Workflow app principal permissions, token audience, App Management/Subscription Settings, and WFM/Service Bus health.
The interesting part is that the ULS failure is occurring deeper in the SPSE token processing path. The nested Workflow Actor request reaches SPSecurityTokenRequestContextV2.InitializeForFederationAuthType, where SharePoint fails to resolve the provider for the runtime Actor issuer and returns invalid_client.
We compared the same trust/issuer path against the working SP2019 source and the Workflow trust resolves correctly on both farms. The difference appears to be in how SPSE constructs/propagates the nested Actor identity before the provider lookup.
This sounds potentially related to what Ax reported above, although I cannot confirm it is the exact same root cause.
Have you seen any known issues with SPWFM REST callbacks / Actor authentication on SPSE after the August 2026 CU, even when KB5002864 is installed? Would you recommend opening a Microsoft support case at this point?
Permalink
Hi Michael,
yes – I would recommend to open a support case to get this analyzed.
Cheers,
Stefan
Permalink
The September update on our non-prod system has broken a simple approval workflow on a list. Running Enable-SPLegacyWorkflow against the site collection has not resolved the issue.
Workflow no longer automatically start when a list item is added. Trying to start it manually yields:
Error
The specified form template could not be found, or is not compatible with rendering in the browser. It might need to be republished as a browser-enabled form.
Click Try again to attempt to load the form again. If this error persists, contact the support team for the Web site.
There is a correlation ID, but when I search for that in the ULS logs I can’t spot a line that relates to the error or gives more useful information
Permalink
Following