n8n-Zugangsdaten rotieren: Secrets tauschen, ohne dass Workflows stehen bleiben

Wenn ein API-Schlüssel oder ein Passwort in einem n8n-Zugangsdatensatz kompromittiert ist, tauschen Sie zuerst den Wert direkt im betroffenen Credential-Datensatz aus, denn Workflows referenzieren Zugangsdaten über eine feste ID und nicht über den gespeicherten Wert, sodass keine Verknüpfung neu angelegt werden muss. Für automatisierte oder zentral verwaltete Rotation über mehrere Umgebungen hinweg bietet n8n mit External Secrets einen eigenen Mechanismus, der allerdings nicht in jeder Edition verfügbar ist. Stand: August 2026.

Was tun Sie sofort bei einem kompromittierten Zugangsdatensatz?

Öffnen Sie den betroffenen Credential-Datensatz in n8n, tragen Sie den neuen Wert ein und speichern Sie. Da alle Workflows den Datensatz über seine ID referenzieren, laufen sie nach dem Speichern automatisch mit dem neuen Wert weiter, ohne dass Sie einzelne Nodes anfassen müssen. Widerrufen Sie parallel den alten Schlüssel direkt beim jeweiligen Anbieter, denn n8n selbst kann einen extern gültigen Schlüssel nicht ungültig machen.

Wie funktioniert External Secrets, und wer darf es nutzen?

External Secrets speichert sensible Werte in einem externen Tresor statt direkt in n8n und lädt sie bei Bedarf nach. Die Funktion ist ausschließlich in den Enterprise-Editionen verfügbar, sowohl Self-hosted als auch Cloud, und fehlt in der Community Edition vollständig.

• Unterstützte Anbieter: 1Password über den Connect Server, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault und Infisical.
• Einrichtung: unter Einstellungen, Externe Secrets, einen neuen Tresor hinzufügen, Anbieter wählen und die anbieterspezifischen Zugangsdaten hinterlegen.
• Nutzung: im gewünschten Credential-Feld über Ausdruck die Referenz {{ $secrets.<tresor-name>.<secret-name> }} eintragen.

Eine wichtige Einschränkung: Secrets aus einem externen Tresor lösen sich ausschließlich in Credential-Feldern auf, nicht in anderen Ausdrücken innerhalb eines Workflows.

Was unterscheidet Credential-Rotation von Encryption-Key-Rotation?

Das sind zwei unterschiedliche Vorgänge, die im n8n-Forum regelmäßig verwechselt werden. Das Ändern eines einzelnen Zugangsdatensatzes betrifft nur diesen einen Datensatz. Das Ändern des N8N_ENCRYPTION_KEY dagegen betrifft die Verschlüsselung sämtlicher gespeicherter Zugangsdaten gleichzeitig, weil dieser Schlüssel die gesamte Credential-Datenbank absichert.

Nutzerberichte im Forum beschreiben nach einer unvorsichtigen Encryption-Key-Rotation immer wieder denselben Fehler: „Credentials could not be decrypted, the likely reason is that a different encryptionKey was used to encrypt the data." Dieser Fehler bedeutet praktisch den Totalverlust aller gespeicherten Zugangsdaten, wenn kein Datenbank-Backup vor der Rotation existiert. Ändern Sie den Verschlüsselungscode deshalb nur mit vorherigem Backup und niemals als Reaktion auf einen einzelnen kompromittierten API-Schlüssel, dafür reicht das Ändern des betroffenen Credential-Datensatzes.

Welchen Notfallpfad gibt es für die Community Edition ohne External Secrets?

Ohne Enterprise-Lizenz bleibt nur der manuelle Weg: den betroffenen Wert im jeweiligen Credential-Datensatz direkt in der Oberfläche austauschen. Für global gültige Zugangsdaten, etwa bei OAuth-Verbindungen, die beim Start automatisch gesetzt werden sollen, bietet n8n zusätzlich Credential Overwrites. Diese Funktion überschreibt Zugangsdaten global über eine REST-API oder eine Umgebungsvariable, ist aber nicht für die Rotation kompromittierter Schlüssel gedacht, sondern für die zentrale Erstkonfiguration. Die Dokumentation rät ausdrücklich von der Umgebungsvariable CREDENTIALS_OVERWRITE_DATA ab, weil Umgebungsvariablen in n8n keinen besonderen Schutz genießen, und empfiehlt stattdessen den Endpunkt-Weg mit optionalem Auth-Token. Wer External Secrets grundsätzlich in Betracht zieht, findet bei NordFlux Unterstützung bei der Einführung.

Häufige Fragen zur Zugangsdaten-Rotation in n8n

Muss ich nach dem Ändern eines Zugangsdatensatzes Workflows neu speichern?

Nein. Workflows referenzieren Zugangsdaten über eine feste ID, sodass eine Änderung am Datensatz automatisch für alle verknüpften Workflows wirkt, sobald Sie den Datensatz speichern.

Was passiert, wenn ich den Verschlüsselungscode ändere?

Ohne vorheriges Datenbank-Backup und sorgfältiges Vorgehen können sämtliche gespeicherten Zugangsdaten mit dem Fehler „Credentials could not be decrypted" unbrauchbar werden. Behandeln Sie diesen Schritt deshalb getrennt von der Rotation einzelner Zugangsdaten und nur mit Backup.

Welche Tresor-Anbieter unterstützt External Secrets?

Unterstützt werden 1Password über den Connect Server, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault und Infisical. Die Funktion steht ausschließlich in den Enterprise-Editionen zur Verfügung.

Kann ich External Secrets auch außerhalb von Credential-Feldern nutzen?

Nein, die Dokumentation stellt klar, dass sich Secrets aus einem externen Tresor ausschließlich in Credential-Feldern auflösen. In anderen Ausdrücken eines Workflows, etwa in einem Code-Node, stehen sie nicht zur Verfügung.