On July 1, 2027, Remote Event Receivers (RERs) will stop working in SharePoint Online. After that date, no remote event receiver will fire events, regardless of how it was registered. If your application still relies on remote event receivers to react to changes in SharePoint, now is the time to plan your move to SharePoint webhooks.

Remote event receivers are part of the SharePoint Add-in model and depend on Azure Access Control Services (Azure ACS) for authentication. With the retirement of Azure ACS now complete, remote event receivers registered using Azure ACS have stopped functioning correctly as of April 2, 2026. They can still be added programmatically, events might still fire, but inside the receiver service ACS cannot be used anymore for delegated or app-only access back into SharePoint.

To give developers more time to migrate, as part of the ACS retirement, we enabled a different registration model that removes the Azure ACS dependency: remote event receivers registered using a Microsoft Entra application. Receivers registered this way continue to work until July 1, 2027, and, unlike Azure ACS–registered receivers, they also work for new tenants onboarded after November 1, 2024. You can read the details in Use remote event receivers without an Azure ACS dependency and the Remote event receivers retirement update.

This extension is a bridge, not a destination. On July 1, 2027, both registration models reach end of the road and all remote event receivers stop firing.

• April 2, 2026 – Remote event receivers registered using Azure ACS stopped functioning correctly.
• July 1, 2027 – All remaining remote event receivers, including those registered using a Microsoft Entra application, stop working. No RER will fire events after this date.

The recommended replacement for remote event receivers is SharePoint webhooks. Webhooks are regular, industry standard, HTTP web APIs, which makes them simpler to build and operate than the WCF services that remote event receivers rely on. When a subscribed event occurs, SharePoint sends an HTTP POST to your service endpoint.

A few things to know as you design your migration:

• Asynchronous only. Webhooks fire after a change has happened (similar to the “-ed” events). Synchronous “-ing” events are not supported, so you can no longer block or cancel an action from a receiver.
• Blocking scenarios need a rethink. If you used synchronous events to prevent unauthorized updates or deletes, consider securing the protected files and folders so they can’t be changed, or moving the data to a hidden library.
• Webhooks currently cover SharePoint list items – that is, changes to items in a list or document library.
• Get the change details yourself. The notification payload tells you something changed, but not what. Call the GetChanges API on the list with a stored change token to retrieve the actual changes.
• Manage expiration. Subscriptions expire after at most 180 days, so your application is responsible for renewing them.
• Or use Microsoft Graph. As an alternative, you can use to subscribe to changes on a SharePoint list. If your application needs to stay continuously up to date of changes happening in SharePoint, then please consult the scan guidance for recommended patterns to use.

1. Inventory your code for remote event receiver registrations and the WCF endpoints that handle them.
2. Stand up an HTTP endpoint to receive webhook notifications, and implement the validation handshake.
3. Create a subscription against the target list or library, store the change token, and call GetChanges when a notification arrives.
4. Re-implement any synchronous blocking logic using the alternative approaches above.
5. Add subscription renewal so your webhooks don’t lapse at the 180-day limit.

• Overview of SharePoint webhooks
• Will remote event receivers also be retired? — Azure ACS retirement FAQ
• Remote event receivers retirement update in SharePoint Online
• Use remote event receivers without an Azure ACS dependency