Power Pages 2026: Die stille Härtungs-Serie

Die Zeitleiste

Alle folgenden Angaben stammen aus dem Microsoft-Learn-Artikel zu den anstehenden Änderungen in Power Pages, Dokumentstand 14. August 2026. Ich habe sie nach Wirksamkeitsdatum sortiert, nicht nach Ankündigungsdatum. Für Betreiber zählt, wann etwas aufhört zu funktionieren.

2022, die Ankündigungswelle. Im Juni 2022 werden gleich zwei Dinge für deprecated erklärt: die OData-Feeds für Listen und der Portal Content Editor. Ebenfalls 2022 wird der OAuth-2.0-Implicit-Grant-Flow in seiner alten Form abgekündigt, mit Migrationsfrist bis Oktober 2022. Und ab Oktober 2022 sind neu erstellte Websites standardmäßig privat, was damals viele überrascht hat.

Das Muster ab 2022. Microsoft schaltet neue Funktionen zuerst für neue Websites ab, lässt bestehende weiterlaufen und setzt das endgültige Ende Jahre später. Bei den OData-Feeds heißt das: ab Oktober 2022 können neue Websites die Funktion nicht mehr nutzen, das Ende für alle kommt im Juni 2026. Fast vier Jahre Vorlauf.

Juni 2026, drei Fristen laufen ab.

• Die OData-Feeds für Listen werden entfernt.
• Der Portal Content Editor wird entfernt.

Die aus meiner Sicht folgenreichste Änderung kommt zuletzt. Ab Juni 2026 erzwingen Websites Table Permissions für alle Formulare und Listen, unabhängig davon, ob die Einstellung "Enable Table Permissions" gesetzt ist. Für neu erstellte Websites gilt das schon seit Release 9.3.7.x.

14. September 2026. Der Wildcard-Wert im Webapi/<tabelle>/fields-Setting wird für alle Websites entfernt.

Vier Fristen in einem Jahr, drei davon im Juni, eine im September. Wer einmal im Quartal auf sein Portal schaut, hat 2026 drei Gelegenheiten, etwas zu übersehen.

Warum Microsoft härtet, und warum das gut ist

Es lohnt sich, kurz bei der Begründung zu bleiben, denn sie ist bei allen vier Punkten dieselbe Logik.

Der Wildcard legt alle Spalten einer Dataverse-Tabelle offen, auch die, die niemand anzeigen wollte. Die Table-Permission-Änderung schließt den Fall, dass ein Formular ohne aktivierte Berechtigungsprüfung mehr Daten liefert, als die Rollen des Nutzers hergeben. Beides sind Änderungen, die etwas wegnehmen, das bequem war und im Zweifel zu viel preisgibt.

Das ist die richtige Richtung, und zwar ausdrücklich. Power Pages ist eine Plattform, auf der Fachbereiche schnell Portale bauen können. Diese Geschwindigkeit ist ihr Wert. Der Preis dafür ist, dass Voreinstellungen ausgesprochen wirksam sind, weil viele Konfigurationen nie bewusst gesetzt, sondern nur nie geändert wurden. Wenn Microsoft solche Voreinstellungen enger zieht, verbessert das die Sicherheitslage tausender Portale auf einmal, auch die derjenigen, die nie ein Audit sehen werden.

Härtung ist allerdings nie ohne Bruchstellen zu haben. Genau die Konfiguration, die eine Plattform großzügig gemacht hat, ist die, auf der über Jahre Lösungen aufgebaut wurden. Wenn sie enger wird, brechen Dinge. Das ist kein Vorwurf an Microsoft, das ist der Mechanismus.

Und daraus folgt für Betreiber eine ziemlich klare Konsequenz.

Die Konsequenz: Release-Radar oder Überraschung

Es gibt für ein produktives Power Pages Portal genau zwei Betriebsmodi.

Der erste: Jemand sieht regelmäßig nach, was Microsoft angekündigt hat, prüft es gegen die konkrete Konfiguration dieses Portals und meldet, was zu tun ist. Regelmäßig heißt monatlich, nicht bei Gelegenheit. Der Aufwand dafür ist gering, weil die meisten Monate nichts Relevantes bringen. Der Wert liegt darin, dass die relevanten Monate nicht durchrutschen.

Der zweite: Niemand sieht nach. Dann erfährt die Organisation von einer Änderung an dem Tag, an dem ein Nutzer anruft, weil das Formular nicht mehr speichert. Der Fix ist dann derselbe wie vorher, er kostet nur ein Vielfaches, weil er unter Zeitdruck, mit Support-Ticket und mit einem verärgerten Fachbereich stattfindet.

Der Unterschied zwischen beiden Modi ist nicht Kompetenz. Ich sehe sehr gute Entwicklerteams im zweiten Modus, schlicht weil niemand die Aufgabe hat. Der Unterschied ist Zuständigkeit. Solange Release-Beobachtung niemandes Job ist, ist sie niemandes Job.

Die Ankündigung zum Wildcard ist am 14. August 2026 in der Dokumentation gelandet. Zwischen diesem Tag und dem Wirksamwerden liegen 31 Tage. Bei den Juni-Fristen waren es Jahre. Der Trend geht zu kürzeren Fristen, und das ist der eigentliche Grund, warum ein jährlicher Blick nicht mehr reicht.

Was hilft: erst Bestandsaufnahme, dann Dauerbetrieb

Zwei verschiedene Probleme, zwei verschiedene Antworten. Man verwechselt sie leicht.

Das Bestandsproblem ist die Frage: Was steht gerade in meinem Portal, und wo bin ich betroffen? Das ist einmalige Arbeit mit einem Ergebnis. Ein Security Audit geht die Konfiguration systematisch durch: Table Permissions, Column Permissions, Web Roles, Web-API-Freigaben, Authentifizierung, Site Visibility. Ergebnis ist ein Befundbericht mit Schweregraden und einer Reihenfolge, was zuerst. Festpreis ab 4.900 Euro netto. Danach wissen Sie, wo Sie stehen, inklusive der Wildcard-Frage und der Table-Permission-Frage.

Das Laufzeitproblem ist die Frage: Wer sagt mir, wenn sich das ändert? Das ist Dauerarbeit ohne Endpunkt, und dafür gibt es Power Pages Care. Ich kümmere mich um Ihr Portal, damit Sie es nicht tun müssen.

Vier Dinge passieren jeden Monat, unabhängig davon, ob gerade etwas los ist.

Es gibt zwei Stufen. Care, 1.290 Euro netto im Monat, deckt Review, Release-Check und Report ab, mit 48 Stunden Reaktionszeit an Werktagen und kleineren Anpassungen bis zwei Stunden im Monat. Das ist die Stufe für stabile Portale, die Gewissheit wollen. Care Plus, 2.490 Euro netto im Monat, enthält alles daraus und zusätzlich einen Quartals-Deep-Dive, bei dem ein Auditbereich in voller Tiefe geprüft wird. Reaktionszeit 24 Stunden, bei Sicherheitsvorfällen am selben Tag, Anpassungen bis fünf Stunden im Monat inklusive kleiner Erweiterungen. Diese Stufe ist für lebende Portale gedacht, für B2C und External ID, für mehrere Umgebungen.

Mindestlaufzeit drei Monate, danach monatlich kündbar, Abrechnung monatlich im Voraus.

Das Prinzip dahinter ist wichtiger als die Zahlen. Care verkauft keine Stundenkontingente, sondern Zuständigkeit. Der Deep-Dive in Care Plus folgt den acht Bereichen des Security Audits, über zwei Jahre entsteht daraus ein rollierendes Vollaudit. Wenn Sie kündigen, bleiben Reports und Dokumentation bei Ihnen. Und Sie wissen immer, wer zuständig ist.

Wenn das Budget nur für eines reicht, machen Sie zuerst die Bestandsaufnahme. Diesen Hinweis gebe ich fast immer. Ein Radar, das auf eine unbekannte Konfiguration schaut, kann Relevanz nicht beurteilen.

Wann Sie keinen Wartungsvertrag brauchen

Weil das sonst wie eine Verkaufsseite klingt, hier der ehrliche Teil. Es gibt Fälle, in denen ein Wartungsvertrag für Sie das falsche Produkt ist, und ich sage das auch im Gespräch.

Sie haben internes Power-Pages-Know-how mit Zuständigkeit. Wenn in Ihrem Team jemand namentlich dafür verantwortlich ist, die Release-Notes und den Deprecations-Artikel monatlich zu lesen, und das seit mehr als einem halben Jahr tatsächlich tut, dann kaufen Sie bei mir etwas, das Sie schon haben. Der Test dafür ist einfach: Fragen Sie diese Person, welche vier Fristen 2026 anstehen. Kommt die Antwort ohne Nachschlagen, sind Sie versorgt.

Ihr Portal ist rein anonym und statisch. Ein Portal ohne Anmeldung, ohne Formulare, ohne Web-API-Nutzung, das im Wesentlichen Inhalte ausliefert, hat sehr wenig Angriffsfläche für genau diese Art von Änderungen. Keine der vier 2026er Fristen trifft es. Hier reicht ein jährlicher Blick.

Das Portal ist auf Abkündigung. Wenn die Ablösung schon beschlossen und terminiert ist und der Termin vor den relevanten Fristen liegt, reparieren Sie nichts, was ohnehin abgeschaltet wird. Prüfen Sie nur, ob der Termin wirklich hält.

Sie sind mitten in einem Projekt mit einem guten Partner. Solange ein Implementierungspartner aktiv am Portal arbeitet und einen Wartungsanteil im Vertrag hat, ist ein zweiter Vertrag daneben Doppelarbeit. Prüfen Sie den bestehenden Vertrag darauf, ob Release-Beobachtung wirklich drinsteht. Oft steht dort Störungsbehebung, und das ist etwas anderes.

Bleiben die Fälle dazwischen, und das sind erfahrungsgemäß die meisten. Ein produktives Portal mit angemeldeten Nutzern, gebaut vor ein bis fünf Jahren, seitdem ohne festen Kümmerer, mit einem Dienstleister, der auf Zuruf kommt. Für diese Konstellation ist die Härtungs-Serie kein abstraktes Thema, sondern eine Terminliste, die niemand führt.

Der nächste Termin ist der 14. September

Prüfen Sie diese Woche, ob Ihr Portal den Wildcard-Wert nutzt. Die Anleitung dafür steht im Engineer-Beitrag und dauert zehn Minuten pro Portal.

Wenn Sie das lieber gemeinsam machen, melden Sie sich einfach. Ich gehe mit Ihnen gemeinsam Ihre Site Settings durch, per Screensharing, Sie wissen danach, ob und wo Sie betroffen sind und wie lange die Behebung dauert.

Schreiben Sie an powerportals@amingi.net.

Ich bin ehemaliger Microsoft MVP für Power Pages (2024 bis 2026) und auf der Plattform seit ihren Adxstudio-Tagen unterwegs.

Verwandte Artikel

Quellen

• Important upcoming changes and deprecations in Power Pages, Dokumentstand 14.08.2026. Grundlage für alle Datumsangaben in der Zeitleiste
• Overview of the Power Pages portals Web API
• Secure your forms und Securing lists
• List OData feeds