What the NetSuite Sandbox Refresh Doesn't Reset

What the Refresh Actually Does

NetSuite sandbox refresh scrubs the NetSuite-side credentials: TBA tokens, OAuth and gateway credentials stored in the token management UI, SSO configurations. It brings the account back to a clean state — from NetSuite's perspective.

That is it.

What It Does Not Touch

SFTP connections to your bank do not live in NetSuite's credential store. They live in your scripts.

The host, username, private key or password, remote directory path — those are either hardcoded in a SuiteScript 2.x Map/Reduce, referenced from a custom record, or sitting in a script parameter that survived the refresh unchanged. The connection exists at the script layer, not the platform layer. NetSuite has no mechanism to reach into your script parameters and zero them out on refresh.

Same goes for:

• Positive-pay file drop connections (EBP, AvidXchange, EastWest, similar)
• ACH file generation scripts with live SFTP targets
• Scheduled scripts that poll a directory or push an outbound file
• Integration credentials stored in a custom record or script parameter rather than in the NetSuite OAuth token store

The moment the refreshed sandbox comes up, every one of those is still pointed at production endpoints. Scheduled scripts will fire on their schedule. If someone runs a saved search export or kicks off a Map/Reduce manually, the file goes where it was always going.

How This Goes Wrong

Had a client where the sandbox refresh happened on a Thursday. By Friday afternoon, someone in accounting ran a test of their check run process — "just to see if the layout was right." The scheduled script that transmitted the positive-pay file ran clean. No errors. File landed at the bank. The bank processed it.

Not a drill.

The assumption was that sandbox means isolated. The environment was refreshed. Therefore everything was safe. That assumption broke the moment the SFTP credentials in the script parameters were treated as part of what the refresh reset.

They were not.

The Post-Refresh Hardening Checklist

A sandbox refresh is not a fresh start. It is the beginning of a re-hardening process.

Immediately after every refresh:

Disable or repoint SFTP connections. Pull up every script that touches a bank SFTP — check script parameters, the custom records used as config, and anything embedded in the script body. Replace live endpoints with a dead hostname or an internal test SFTP you control. Do this before anyone touches the environment.

Disable scheduled scripts that transmit files. Go to Customization > Scripting > Script Deployments. Anything that pushes payment files — positive-pay, ACH, remittance — disable it on arrival. Do not assume they are paused by default post-refresh.

Audit integration records. Any third-party integration that pushes outbound files — AP automation, bank file drop middleware — check the endpoint configuration. If it came through as part of the refreshed data, it came through pointed at production.

Verify before you let anyone work in the box. This is a sign-off step, not a suggestion. The technical lead or NetSuite admin needs to confirm that no script in the environment is holding a live bank endpoint before testing begins.

NetSuite gives you a warning that credentials are cleared. It does not give you a warning that your payment file transmission logic is still armed.

Bottom Line

The sandbox refresh resets what NetSuite controls.

Your SFTP connections, your file-drop scripts, your scheduled ACH and positive-pay transmissions — those are yours to harden, every single time.

The mental model of "refresh equals isolation" is accurate for the platform layer. It is wrong for the payment layer. And the payment layer is the one where being wrong costs real money.

Treat every sandbox refresh as the start of a hardening process, not the end of a risk period.