Cloud outages and API keys: How businesses can prepare

Information checked: 1 November 2026. A website can remain accessible while a supplier incident disrupts integrations, credential rotation, new deployments or reporting. For companies in Switzerland and Germany, understanding how their systems depend on each other is the first step towards a workable response.

What Railway reported

In October 2026, hosting provider Railway reported unauthorised access to internal systems. Its preliminary report said that stored environment variables for a subset of workspaces may have been decrypted. These variables can contain API keys and database credentials. Railway advised existing customers to rotate sensitive credentials as a precaution. Builds and deployments were paused during the investigation; according to Railway, existing customer deployments stayed online. Its investigation was still ongoing when the report was published. Railway preliminary report.

The PHP vulnerabilities announced around the same time are a separate event. Timing alone does not establish a connection. A service taken offline as a precaution is not evidence that its operator was attacked.

How a hidden dependency develops

An API key lets software access another service. Environment variables can keep credentials separate from source code, but they are not inherently secure: depending on the setup, someone with access to the runtime or its management interface might also read them.

Consider three illustrative situations: an employee tests a marketing tool using a key with broad CRM permissions; a developer pastes a key into a shared support ticket; or a former supplier retains access because the integration was not included in offboarding. These are examples, not claims about Railway. Employees need a clear, blame-free route to report mistakes or suspicious access. Training helps, but does not replace restricted permissions and technical safeguards.

Five preparations to make now

1. Map important journeys, such as website form → integration → CRM → sales owner. Record the responsible people and providers without copying secret values into the inventory.

2. Review service accounts, key owners, access rights and unused connections. Give each integration only the permissions it needs and protect administrative accounts with MFA.

3. Use appropriate secret management, limit access and check logs or debug output for accidental exposure. Avoid placing keys in code, chats, shared documents or tickets. GitHub: secret leakage risks.

4. Monitor both errors and missing expected events. Define an owner, a backup contact and an alternative escalation channel in case the provider itself is unavailable.

5. Keep recovery documentation accessible independently, test backups and practise a fallback for critical processes. The Swiss BACS guidance for SMEs covers limited access and backup testing.

If a secret may have been exposed

Have the responsible IT team or provider assess the exposure, restrict access and revoke or rotate affected credentials using the supplier's instructions. Install replacement credentials securely, test dependent services and examine available access and usage logs. Deleting a key from a file does not invalidate it. The response sequence depends on the incident and the need to contain it. GitHub: remediating a leaked secret.

Involve your privacy lead promptly if personal data may be affected. Swiss notification to the FDPIC depends on conditions including a likely high risk to the people concerned. Where the GDPR applies, a notifiable personal-data breach must generally be reported without undue delay and, where feasible, within 72 hours; the thresholds differ. Swiss FDPIC · German BfDI.

Start with one critical journey and review its providers, credentials, alerts and fallback with your IT partner. This is a practical starting point, not a substitute for a full security assessment. Explore process automation.