Eine geschäftskritische Marketingumgebung muss nicht sichtbar zum Stillstand kommen, um den Geschäftsbetrieb zu beeinträchtigen. Journeys können weiterlaufen, Automatisierungen planmäßig ausgeführt werden und Dashboards scheinbar normal funktionieren, während ein wesentlicher Datenfluss im Hintergrund bereits unterbrochen ist. In komplexen Salesforce Marketing Cloud Engagement-Umgebungen liegt das eigentliche Risiko daher häufig nicht in einem klar erkennbaren Plattformausfall, sondern in einer Integration, die unbemerkt keine aktuellen Daten mehr empfängt oder verarbeitet.
Dieses Risiko wird im September 2026 besonders konkret. Salesforce lässt bestehende Client Secrets von Installed Packages, die seit dem 25. März 2026 nicht rotiert wurden, am 30. September ablaufen. Neu generierte und rotierte Secrets erhalten anschließend eine Gültigkeitsdauer von 180 Tagen. Was zunächst wie eine technische Sicherheitsänderung erscheint, führt damit zu einer wiederkehrenden Management- und Kontinuitätsanforderung für Unternehmen, die Marketing Cloud Engagement mit CRM, Middleware, Datenplattformen, Websites, Anwendungen und anderen Geschäftssystemen verbinden.
Bei kleineren und überschaubaren Implementierungen kann der Austausch eines Client Secrets relativ einfach sein. In einer Enterprise-Landschaft ist die Situation anders. Über Jahre gewachsene Integrationen können auf mehrere Business Units, Dienstleister und Anwendungen verteilt sein. Nicht immer ist unmittelbar ersichtlich, wer Eigentümer ist, welche Systeme dieselben Zugangsdaten verwenden und welche kommerziellen Prozesse von den Daten abhängig sind, die über eine solche Integration fließen. Genau an diesem Punkt wird aus einer Sicherheitsmaßnahme eine Governance-Frage.
Die relevante Frage für das C-Level lautet daher nicht, ob ein Administrator rechtzeitig vor der Frist ein neues Secret generieren kann. Entscheidend ist, ob das Unternehmen ausreichend Transparenz über seine Marketing Cloud-Integrationslandschaft besitzt, um eine solche Änderung kontrolliert durchzuführen, ohne Kundenkommunikation, Lead-Prozesse, Reporting oder andere kommerzielle Aktivitäten unbeabsichtigt zu beeinträchtigen.
Client Secrets werden verwendet, damit sich Anwendungen sicher authentifizieren und auf API-Funktionalitäten zugreifen können. Dadurch werden sie schnell als Bestandteil der technischen Administration betrachtet. Der geschäftliche Wert, der hinter solchen Zugangsdaten steht, ist jedoch häufig wesentlich größer. Dieselbe Authentifizierung kann beispielsweise die Bereitstellung von Kundendaten, die Aktualisierung von Lead-Status, den Austausch von Kampagneninformationen oder Datensätze unterstützen, die anschließend in Automation Studio und Journey Builder verwendet werden.
Fällt die Authentifizierung aus, muss Marketing Cloud Engagement selbst deshalb nicht zwingend nicht verfügbar sein. Eine externe Anwendung kann die Bereitstellung neuer Daten einstellen, während bestehende Automatisierungen planmäßig weiterlaufen. Eine Kampagne kann weiterhin ausgeführt werden, jedoch mit einer unvollständigen Zielgruppe. Eine Journey kann aktiv bleiben, während keine neuen Kontakte mehr aufgenommen werden. Reporting kann verfügbar bleiben, obwohl der zugrunde liegende Datensatz nicht mehr vollständig aktualisiert wird.
Das Risiko entsteht gerade dadurch, dass technische Ursache und geschäftliche Auswirkung mehrere Schritte voneinander entfernt sein können. Der technische Fehler tritt bei der Authentifizierung auf, während die sichtbare Konsequenz möglicherweise erst später bei der Kampagnenperformance, in Customer Journeys, im Lead Management oder in Managementinformationen erkennbar wird. Teams, die unterschiedliche Teile derselben Kette verantworten, können deshalb jeweils zu dem Schluss kommen, dass ihre eigene Komponente ordnungsgemäß funktioniert.
Für das Management ist das ein wichtiger Unterschied. Plattformverfügbarkeit ist nicht gleichbedeutend mit der Kontinuität eines Geschäftsprozesses. Eine Enterprise Marketing Cloud-Umgebung besteht aus weit mehr als den Salesforce-Komponenten, die auf dem Bildschirm sichtbar sind. Die tatsächliche Leistungserbringung hängt von der gesamten Kette aus Quellen, APIs, Integrationsschichten, Datenflüssen, Automatisierungen und nachgelagerten Prozessen ab. Eine Schwachstelle in nur einer dieser Verbindungen kann daher unverhältnismäßig große Auswirkungen haben.
Die meisten Enterprise-Umgebungen werden nicht in einer einzigen Phase entwickelt. Sie wachsen über Jahre, werden von unterschiedlichen Implementierungspartnern erweitert und erhalten neue Integrationen, wenn sich Geschäftsmodelle, Technologien oder Datenanforderungen verändern. Dadurch entsteht eine Landschaft, in der technisch gut funktionierende Integrationen nicht zwangsläufig auch gut dokumentiert sind. Ein Installed Package kann vor Jahren von einem Mitarbeiter oder Dienstleister angelegt worden sein, der heute nicht mehr beteiligt ist, während die Integration selbst weiterhin täglich einen wichtigen Geschäftsprozess unterstützt.
Die regelmäßige Rotation von Secrets wird damit auch zu einem Test für die Reife des Integrationsmanagements. Ein Unternehmen, das schnell feststellen kann, welche Anwendungen ein Installed Package verwenden, wer dafür verantwortlich ist und welche Prozesse von einer Änderung betroffen sind, hat seine Architektur auch aus Governance-Sicht unter Kontrolle. Müssen diese Informationen dagegen erst aus alter Dokumentation, Skripten, Dienstleisterwissen und dem Wissen einzelner Mitarbeiter rekonstruiert werden, ergibt sich ein anderes Bild. Die technische Landschaft funktioniert zwar, bleibt organisatorisch jedoch anfällig.
Diese Anfälligkeit kann unter normalen Umständen weitgehend unsichtbar bleiben. Solange Zugangsdaten unbegrenzt funktionieren, besteht wenig operative Veranlassung, eine alte Integration erneut zu untersuchen. Ein verpflichtender Lifecycle durchbricht dieses Muster. Jede Rotation erfordert erneut Wissen darüber, wie die Zugangsdaten verwendet werden, und zwingt das Unternehmen dazu, regelmäßig zu prüfen, ob die dokumentierte Landschaft noch der tatsächlichen Realität entspricht.
Die anfälligste Integration ist nicht zwingend die technisch schwächste Verbindung, sondern diejenige, bei der niemand mehr genau weiß, welche Geschäftsprozesse davon abhängig sind.
Diese Perspektive verdeutlicht zugleich, warum das Thema nicht ausschließlich bei IT oder Marketing Operations angesiedelt werden kann. Der Wert der Integration entsteht letztlich in einem Geschäftsprozess. Ist eine Verbindung für Leadgenerierung, transaktionale Kommunikation, Kundensegmentierung oder kommerzielles Reporting geschäftskritisch, sollte ihre Kontinuität mit derselben Risikodisziplin bewertet werden wie andere digitale Prozesse, von denen Umsatz und Kundenbetreuung abhängen.
Ein ausgereifter Ansatz beginnt daher nicht mit der Frage, welche Secrets demnächst ablaufen, sondern mit der Frage, welche Integrationen tatsächlich geschäftskritisch sind. Das Ablaufdatum ist eine wichtige technische Information, sagt jedoch nichts über die Auswirkungen eines Ausfalls aus. Zwei Installed Packages können am selben Tag ein neues Secret benötigen, während das eine lediglich ein begrenztes internes Hilfsmittel unterstützt und das andere Teil eines Datenflusses ist, der täglich Millionen von Kundeninteraktionen beeinflusst.
Die technische Konfiguration muss deshalb mit dem geschäftlichen Kontext verbunden werden. Für jede relevante Integration sollte nicht nur klar sein, welches Installed Package und welche Client-Anwendung verwendet werden, sondern auch, welche Funktion die Integration erfüllt, welche Prozesse davon abhängig sind und wer Verantwortung trägt, wenn Änderungen erforderlich sind. Erst dann kann die Priorisierung anhand der Geschäftsauswirkungen erfolgen und nicht ausschließlich anhand technischer Dringlichkeit.
Dafür ist nicht zwingend eine neue Governance-Ebene oder eine separate Administration speziell für Marketing Cloud erforderlich. Effektiver ist es, relevante Integrationen in bestehende Prozesse für Architektur, Konfigurationsmanagement, Change Management und Risikomanagement einzubinden. Marketing Cloud Engagement ist in einer Enterprise-Umgebung kein isoliertes Marketinginstrument. Es ist Bestandteil eines größeren technologischen Ökosystems, in dem Kundendaten, Kommunikation und kommerzielle Entscheidungsfindung miteinander verbunden sind.
Auch Lifecycle Management gehört in dieses Modell. Durch die neue Gültigkeitsdauer von 180 Tagen wird der Austausch von Secrets zu einem wiederkehrenden Prozess. Eine einmalige Bestandsaufnahme im September bringt daher wenig, wenn dieselben Informationen sechs Monate später erneut erhoben werden müssen. Ownership, Abhängigkeiten und Ablaufdaten müssen aktuell bleiben und Bestandteil des regulären Managements werden.
Die Änderung kann damit als sinnvoller Katalysator dienen. Unternehmen erhalten einen konkreten Anlass, festzustellen, welche Packages tatsächlich noch verwendet werden, wo historische Abhängigkeiten entstanden sind und welche Integrationen unzureichend dokumentiert sind. Alte oder überflüssige Verbindungen können überprüft werden, während geschäftskritische Integrationen gezielter in das Management aufgenommen werden. Security schafft damit nicht nur eine neue technische Verpflichtung, sondern kann zugleich die Qualität der Integrationslandschaft verbessern.
Salesforce unterstützt für OAuth 2.0-Integrationen einen gestuften Rotationsprozess. Zunächst kann ein neues Client Secret generiert werden, während das bestehende Secret aktiv bleibt. Anwendungen, die das Installed Package verwenden, können anschließend auf das neue Secret umgestellt und getestet werden. Nachdem bestätigt wurde, dass die Clients korrekt funktionieren, kann das neue Secret aktiviert und das vorherige widerrufen werden.
Dieser Mechanismus ermöglicht einen kontrollierten Übergang und reduziert die Notwendigkeit von Ausfallzeiten. Die technische Funktion allein garantiert jedoch keine Kontinuität. Wenn nicht bekannt ist, welche Anwendungen das Package verwenden, kann ein vergessener Client erst nach der Aktivierung ausfallen. Der gestufte Prozess funktioniert deshalb am besten, wenn Dependency Management und Change Management bereits etabliert sind.
Auch der Testansatz verdient besondere Aufmerksamkeit. Eine erfolgreiche Authentifizierung beweist, dass eine Anwendung mit dem neuen Secret eine Verbindung herstellen kann, sagt jedoch wenig über die vollständige Geschäftsfunktion aus. Ein Datenfluss kann technisch erfolgreich sein, obwohl Datensätze unvollständig ankommen, Volumen abweichen oder nachgelagerte Prozesse nicht dieselbe Ausgabe erhalten wie vor der Änderung. Bei geschäftskritischen Integrationen muss die Validierung daher über den technischen API-Aufruf hinausgehen.
Das bedeutet, dass IT und Marketing unterschiedliche, aber sich ergänzende Verantwortlichkeiten haben. Technische Teams können feststellen, ob Authentifizierung, Konnektivität und Datenübertragung korrekt funktionieren. Der Eigentümer des Geschäftsprozesses muss beurteilen, ob das kommerzielle Ergebnis weiterhin stimmt. Eine aktive Journey ist nicht automatisch eine gesunde Journey; eine erfolgreich abgeschlossene Automation beweist nicht, dass die Eingangsdaten vollständig waren.
Dasselbe gilt für das Monitoring nach der Aktivierung. Einige Integrationen authentifizieren sich kontinuierlich, andere nur während geplanter Batches oder bestimmter Prozesse. Ein Fehler muss daher nicht unmittelbar nach der Änderung sichtbar werden. Der Beobachtungszeitraum sollte sich am normalen Nutzungszyklus der Integration und an den möglichen Auswirkungen orientieren, wenn Daten fehlen oder Prozesse verzögert werden.
Der neue Secret-Lifecycle betrifft Verantwortlichkeiten, die in vielen Unternehmen auf unterschiedliche Funktionen verteilt sind. Security konzentriert sich auf den Schutz von Zugangsdaten und die Begrenzung unbefugter Zugriffe. IT verwaltet Plattformen, Integrationen und technische Änderungen. Marketing Operations überwacht Kampagnen, Journeys und datengetriebene Prozesse. Externe Dienstleister können gleichzeitig für Anwendungen verantwortlich sein, in denen das neue Secret letztlich implementiert werden muss.
Eine solche Aufgabenteilung ist an sich kein Problem. Das Risiko entsteht, wenn die Verantwortung für die vollständige Kette nirgends ausdrücklich zugeordnet ist. Jede Partei kann ihre eigene Komponente korrekt verwalten, während niemand dafür verantwortlich ist festzustellen, ob die End-to-End-Geschäftsfunktion nach einer Änderung noch funktioniert. Für C-Level-Governance ist gerade diese letzte Frage entscheidend.
Ein ausgereiftes Kontrollmodell verbindet deshalb technische Verantwortung mit geschäftlicher Verantwortung. Das Management muss nicht wissen, wie ein Client Secret generiert wird, sollte sich jedoch darauf verlassen können, dass bei kritischen Integrationen eindeutig feststeht, wer die Änderung durchführt, wer die geschäftlichen Auswirkungen versteht, wer das Ergebnis validiert und wer handelt, wenn das Monitoring eine Abweichung zeigt. Die wichtigsten Unterschiede zwischen reaktivem Management und Enterprise-Governance werden dadurch sichtbar:
| Governance-Frage | Reaktives Management | Enterprise-Ansatz |
|---|---|---|
| Abhängigkeiten | Werden untersucht, wenn eine Änderung erforderlich wird | Sind vorab Anwendungen und Geschäftsprozessen zugeordnet |
| Ownership | Ist auf Teams und Dienstleister verteilt | Technische und geschäftliche Verantwortung sind eindeutig |
| Priorität | Wird durch die nächste technische Frist bestimmt | Wird durch Geschäftsauswirkungen und Kontinuitätsrisiko bestimmt |
| Validierung | Prüft hauptsächlich, ob die Verbindung wieder funktioniert | Validiert die vollständige End-to-End-Geschäftsfunktion |
| Lifecycle | Jede Rotation wird erneut organisiert | Rotation ist Bestandteil eines strukturierten Kontroll- und Change-Prozesses |
Die erste große Frist am 30. September 2026 ist daher weniger bedeutend, als sie zunächst erscheint. Unternehmen müssen selbstverständlich verhindern, dass bestehende nicht rotierte Secrets automatisch ablaufen und dadurch Integrationen unterbrochen werden. Wer sich jedoch ausschließlich auf dieses Datum konzentriert, behandelt eine strukturelle Veränderung wie ein einmaliges Projekt. Nach jeder erfolgreichen Rotation beginnt erneut ein Lifecycle von 180 Tagen.
Ein ausgereiftes Unternehmen wechselt deshalb vom Deadline Management zum Lifecycle Management. Ablaufdaten werden rechtzeitig erkannt, doch die Vorbereitung beginnt lange bevor eine Expiration dringend wird. Ownership wird erneut bestätigt, Veränderungen in der Landschaft werden geprüft und relevante Dienstleister erhalten ausreichend Zeit, ihre Anwendungen anzupassen. Die Rotation kann dann in den normalen Change-Zyklus integriert werden, statt kurz vor Ablauf der Zugangsdaten unter Zeitdruck durchgeführt zu werden.
Dieser wiederkehrende Zyklus bietet darüber hinaus einen zusätzlichen Nutzen. Jede Überprüfung schafft die Möglichkeit festzustellen, ob eine Integration noch notwendig ist, ob dieselben Teams weiterhin verantwortlich sind und ob neue Abhängigkeiten entstanden sind. Die Secret-Rotation wird damit Teil einer wiederkehrenden Qualitätskontrolle der Integrationslandschaft. Was als Sicherheitsmaßnahme begann, unterstützt zugleich architektonische Disziplin und operative Steuerbarkeit.
Für Geschäftsführung und Senior Management steht dies im Zusammenhang mit einer umfassenderen Fragestellung rund um Marketingtechnologie. Viele Unternehmen haben in den vergangenen Jahren erheblich in mehr Daten, stärkere Automatisierung und stärker integrierte Kundeninteraktionen investiert. Gleichzeitig ist ihre Abhängigkeit von der zugrunde liegenden Technologielandschaft gestiegen. Die Reife von Marketing Cloud kann deshalb nicht ausschließlich anhand der Anzahl verfügbarer Journeys, Automatisierungen oder Datenquellen gemessen werden. Ebenso wichtig ist, in welchem Maß das Unternehmen die Abhängigkeiten hinter diesen Möglichkeiten versteht und steuert.
Ein skalierbares Marketing Cloud Operating Model verbindet deshalb Innovation mit Kontrolle. Neue Integrationen können relativ schnell Mehrwert schaffen, sollten jedoch von Beginn an klares Ownership, Dokumentation und einen definierten Lifecycle erhalten. Sicherheitsänderungen sollten ausführbar sein, ohne zunächst historisches Wissen rekonstruieren zu müssen. Und wenn kritische Zugangsdaten ersetzt werden, sollte bereits vorher feststehen, welche Prozesse anschließend nachweislich weiter funktionieren müssen.
Die Einführung des Ablaufs von Client Secrets macht einen zuvor weitgehend verborgenen Aspekt von Marketing Cloud Engagement plötzlich sichtbar. Die unmittelbare Aufgabe ist technisch: bestehende Secrets rechtzeitig rotieren und künftig ihre begrenzte Lebensdauer berücksichtigen. Die strategische Aufgabe ist umfassender. Unternehmen müssen sicherstellen, dass kritische Marketingintegrationen nicht nur technisch funktionsfähig sind, sondern auch steuerbar bleiben, wenn sich Zugangsdaten, Plattformanforderungen, Dienstleister oder Architekturen verändern.
Darin liegt die eigentliche Relevanz für C-Level-Stakeholder. Marketingtechnologie unterstützt zunehmend Prozesse, die unmittelbar mit Kundenerlebnis, Umsatz, Compliance und Managementinformationen verbunden sind. Integrationskontinuität ist deshalb kein Detail der Administration, sondern Bestandteil der digitalen Geschäftskontinuität. Das Management muss die Technologie nicht selbst verwalten, sollte sich jedoch auf ein Operating Model verlassen können, in dem Risiken, Ownership und Kontrolle nachweislich geregelt sind.
Unternehmen, die die bevorstehende Rotation ausschließlich als technische Wartungsaufgabe behandeln, können die nächste Frist zwar einhalten, ändern jedoch wenig an ihrer strukturellen Anfälligkeit. Unternehmen, die diesen Zeitpunkt nutzen, um Abhängigkeiten, Ownership und Lifecycle Management neu zu organisieren, schaffen dagegen eine Marketing Cloud-Landschaft, die zukünftigen Plattform- und Sicherheitsänderungen besser standhalten kann.
CloudEngagePro unterstützt Unternehmen dabei, Salesforce Marketing Cloud Engagement mit der übergeordneten Enterprise-Architektur, Datenorganisation und Governance zu verbinden. Im Mittelpunkt steht nicht nur die technische Konfiguration einer Integration, sondern auch die Frage, wie Marketing, IT und weitere Stakeholder gemeinsam für Skalierbarkeit, Kontrolle und Kontinuität sorgen. Genau dieses Zusammenspiel entscheidet letztlich darüber, ob eine Marketing Cloud-Umgebung auf Enterprise-Niveau dauerhaft steuerbar bleibt.
Eine integrierte Salesforce-Architektur verbindet Marketing, Vertrieb und Daten, ohne kritische Abhängigkeiten aus dem Blick zu verlieren, wenn Prozesse und Systeme weiter skalieren.
Klare Lifecycle-Status, Ownership und Übergabepunkte verhindern, dass Marketing- und Vertriebsprozesse von unklaren Verantwortlichkeiten und schwer steuerbaren Ausnahmen abhängig werden.
Revenue Operations verbindet Daten, Prozesse und Verantwortlichkeiten, damit kommerzielle Entscheidungen nicht von isolierten Systemen, getrennten Teams und schwer steuerbaren Datenflüssen abhängen.