Power Pages 2026: The Quiet Hardening Series

The timeline

Everything below comes from the Microsoft Learn article on upcoming changes in Power Pages, document date 14 August 2026. I have sorted it by effective date rather than announcement date. For an operator, what matters is when something stops working.

2022, the announcement wave. In June 2022 two things are declared deprecated at once: OData feeds for lists, and the portal content editor. Also in 2022, the old form of the OAuth 2.0 implicit grant flow is deprecated, with a migration deadline of October 2022. And from October 2022 newly created sites are private by default, which surprised a lot of people at the time.

The pattern from 2022 onward. Microsoft first switches a capability off for new sites, lets existing ones keep running, and sets the real end years later. For OData feeds that means: from October 2022 new sites cannot use the feature, and the end for everyone lands in June 2026. Nearly four years of runway.

June 2026, three deadlines land.

• OData feeds for lists are removed.
• The portal content editor is removed.

The change with the widest blast radius comes last. From June 2026, sites enforce table permissions for all forms and lists, regardless of whether the "Enable Table Permissions" setting is on. For newly created sites this has applied since release 9.3.7.x.

14 September 2026. The wildcard value in the Webapi/<table>/fields setting is removed for all sites.

Four deadlines in one year, three of them in June and one in September. If you look at your portal once a quarter, 2026 gives you three chances to miss something.

Why Microsoft is hardening, and why that is good

It is worth staying with the reasoning for a moment, because the same logic runs through all four items.

The wildcard exposes every column of a Dataverse table, including the ones nobody meant to publish. The table permission change closes the case where a form without permission checking hands back more data than the user's roles would allow. Both changes take away something that was convenient and, in the worst case, gave away too much.

That is the right direction, and I mean that without qualification. Power Pages is a platform where business teams can build portals quickly. That speed is its value. The price is that defaults matter enormously, because a great many settings were never deliberately chosen, they were only never changed. When Microsoft tightens defaults like that, the security posture of thousands of portals improves at once, including all the ones that will never see an audit.

But hardening never comes without breakage. The very configuration that made a platform generous is the configuration that solutions were built on for years. Tighten it and things break. That is not a complaint about Microsoft, it is simply the mechanism.

And it leads to a fairly clear consequence for whoever operates the portal.

The consequence: a release radar, or a surprise

A production Power Pages portal has exactly two operating modes.

The first. Someone checks regularly what Microsoft has announced, tests it against the actual configuration of this portal, and reports what needs doing. Regularly means monthly, not when it comes up. The effort is small, because most months turn up nothing relevant. The value is that the relevant months do not slip through.

The second. Nobody checks. Then the organisation learns about a change on the day a user calls because the form no longer saves. The fix is the same as it would have been, it just costs several times as much, because now it happens under time pressure, with a support ticket open and an unhappy business unit waiting.

The difference between the two modes is not competence. I see very good developer teams in the second mode, simply because nobody owns the task. The difference is ownership. As long as watching releases is nobody's job, it is nobody's job.

One number for scale. The wildcard announcement landed in the documentation on 14 August 2026. Between that day and the effective date sit 31 days. For the June deadlines it was years. The trend is toward shorter notice, and that is the real reason an annual look is no longer enough.

What helps: first an inventory, then an operating routine

Two different problems, two different answers. They are easy to confuse.

The inventory problem is the question: what is actually in my portal right now, and where am I affected? That is one off work with a result. A security audit walks the configuration systematically: table permissions, column permissions, web roles, Web API exposure, authentication, site visibility. The deliverable is a findings report with severities and an order of work. Fixed price from 4,900 EUR net. Afterwards you know where you stand, including the wildcard question and the table permission question.

The runtime problem is the question: who tells me when this changes? That is continuous work with no end point, and it is what Power Pages Care exists for. I look after your portal so you do not have to.

Four things happen every month, whether or not anything is going on.

There are two tiers. Care at 1,290 EUR net per month covers the review, the release check and the report, with a 48 hour response time on business days and smaller adjustments up to two hours a month. That is the tier for stable portals that want certainty. Care Plus at 2,490 EUR net per month includes everything in Care plus a quarterly deep-dive that takes one audit area in full depth. Response within 24 hours, same day for security incidents, adjustments up to five hours a month including small enhancements. That tier is built for living portals, for B2C and External ID, for multiple environments.

Minimum term three months, monthly after that, billed monthly in advance.

The principle behind it matters more than the numbers. Care does not sell buckets of hours, it sells ownership. The Care Plus deep-dive follows the eight areas of the Security Audit, so over two years you get a rolling full audit. If you cancel, the reports and documentation stay with you. And you always know who to call.

If the budget only covers one, do the inventory first. I give that advice almost every time. A radar pointed at an unknown configuration cannot judge relevance.

When you do not need a maintenance contract

Since this would otherwise read like a sales page, here is the honest part. There are cases where a maintenance contract is the wrong product for you, and I say so on the call.

You have in house Power Pages knowledge with clear ownership. If someone on your team is named as responsible for reading the release notes and the deprecations article every month, and has actually been doing it for more than six months, then you would be buying something you already have. The test is simple: ask that person which four deadlines fall in 2026. If the answer comes without looking it up, you are covered.

Your portal is anonymous and static. A portal with no sign in, no forms, no Web API usage, essentially serving content, has very little surface for this class of change. None of the four 2026 deadlines touches it. An annual look is enough here.

The portal is on its way out. If the replacement is already decided and scheduled, and the date falls before the relevant deadlines, do not repair something that is being switched off anyway. Just verify that the date actually holds.

You are mid project with a good partner. As long as an implementation partner is actively working on the portal and has a maintenance component in the contract, a second contract alongside is duplicated work. Do check the existing contract for whether release monitoring is genuinely in scope. Often what is in there is incident response, and that is a different thing.

That leaves the cases in between, and in my experience those are most of them. A production portal with signed in users, built one to five years ago, no dedicated owner since, and a service provider who shows up when called. For that setup the hardening series is not an abstract topic. It is a list of dates that nobody is keeping.

The next date is 14 September

Check this week whether your portal uses the wildcard value. The instructions are in the engineer post and take ten minutes per portal.

If you would rather do it together, get in touch. I will walk through your site settings with you over a screen share, and you will know afterwards whether and where you are affected and how long remediation takes.

Write to powerportals@amingi.net.

I am a former Microsoft MVP for Power Pages (2024 to 2026) and have been on the platform since its Adxstudio days.

Related Articles

Sources

• Important upcoming changes and deprecations in Power Pages, document date 14 August 2026. Basis for every date in the timeline
• Overview of the Power Pages portals Web API
• Secure your forms and Securing lists
• List OData feeds