Chainstack customers must disable old node credentials

By Marcus Bennett

Chainstack customers have two active node-credential sets during a rotation, and the old set must be disabled before the process is complete. The required order is equally clear: move applications to the replacement credentials first, then deactivate the old ones. Both sets remain active in between. Chainstack says: “Generating new credentials alone does not complete the process.”

That sequencing turns credential rotation into a customer-operated cutover. Replacement credentials have no effect on an application until that application uses them. Old credentials do not expire simply because a new set exists. They remain usable during the overlap and stop working only after the customer deactivates them.

Chainstack’s guidance states: “Once customers deactivate the old credentials, requests that use them are rejected.” That rejection marks the operational end of the rotation. Before it happens, an operator may have generated replacements and still be running under the original credentials, leaving the rotation unfinished.

What has to happen during the switch?

Chainstack sets out three actions in a fixed order:

• Generate replacement node credentials.
• Move applications from the old credentials to the replacement set.
• Deactivate the old node credentials, after which requests using them are rejected.

The first action creates a usable alternative. The second transfers applications to it. The third removes the previous access path. The overlap gives customers room to complete the application move before their previous credentials stop working.

Neither generating nor deploying the new set closes the process on its own. That is why Chainstack’s updated guidance adds a practical switchover step to its earlier credential-rotation coverage. Customers need an explicit deactivation action after their applications have moved, rather than assuming that replacement has revoked the previous set.

Does the multichain authentication token change?

No. Chainstack says its node-credential rotation process does not change a multichain authentication token. The guidance separates the node-credential switchover from that token, so completion of one does not amount to a change to the other.

Chainstack’s earlier recommendations also remain relevant. The company has asked customers to rotate node credentials, change passwords, regenerate platform API keys if used, and watch for phishing. Those broader steps sit alongside the switchover; they do not remove the requirement to deactivate the old node credentials.

Did Chainstack change customer systems?

Chainstack did not modify customer nodes, the console, or the API. Customer-facing services continued operating. The update describes a procedure for customers to follow, not an automatic infrastructure change or a silent migration of their applications.

Because the platform did not rewrite customer-side configurations, the burden falls to customers to identify and update the applications that rely on the affected node credentials. The practical distinction is between creating the replacement and completing the rotation. Only the latter requires the old set to be disabled after the application move.

What does this change for Chainstack customers? It changes the test for declaring a node-credential rotation complete. A customer cannot stop after generating a new set; the old set remains active through the application transition and must then be disabled.

That overlap explains why deactivation is more than routine cleanup. While both sets remain active, old access has not ended. The guidance does not describe the platform revoking the previous set automatically, which leaves the final security step with the customer.

For operators, the practical check is whether every application has moved before deactivation. If it has, the final action will cause requests using the old credentials to be rejected. If it has not, those requests can continue working until the move and deactivation are complete.

The next checkpoint is therefore customer action rather than a platform-side event: complete the application migration, deactivate the old node credentials, and only then treat the rotation as finished.