Secure your NetSuite account before somebody tests it

What to check in your NetSuite account now, while nothing’s on fire: scripts open to the outside, integration roles, SSO, passkeys and login alerts.

Most NetSuite accounts have never had anybody look at them the way an attacker would. The ones that get looked at usually get looked at the week after something happened.

Around 3:00 one afternoon, a client of ours started getting a flood of NetSuite lockout emails for their employees. Their people were locked out of NetSuite, and there were files in the File Cabinet that nobody on staff had created. Every way in was something they could have closed ahead of time. Here’s how it happened.

Nobody had to break a password to lock them out. NetSuite locks a user out for 30 minutes after five failed logins in a row. That’s a good control against guessing a password, but it also means anybody who knows your login emails can lock your staff out on purpose, over and over, just by failing five times.

And the login emails weren’t hard to find. The company had a team page on its website with everybody’s name on it. Most companies use first.last@ or firstinitiallast@, so a list of names is a list of usernames.

The files were the part that got our attention. That means something let an outside party write into the account. It turned out to be a script, the Sticky Notes upload, reachable from any web store account.

Here’s what to check in your own account now, while nothing’s on fire.

How they found the usernames

Look at your own site the way an attacker would. A team page, a staff directory, press releases with names in them, a “contact our sales team” page with direct emails. Any of those gives somebody a starting list.

We’re not saying take the team page down. It’s good for business. But if names are public, the login has to hold up without the username being a secret, which is what SSO and passkeys below are for.

NetSuite’s own login page doesn’t help them. A bad email and a bad password get the same message: “You have entered an invalid email address or password.” They don’t need it to. A team page and a good guess at your email format is enough, and every right guess locks somebody out.

Scripts open to the outside

This is where the files came from, and it’s where we spend most of the review.

Suitelets are the big one. A Suitelet deployed with Available Without Login checked is a public URL. Anybody who finds it can run it. If that Suitelet writes a file, creates a record or sends an email, so can they.

The second thing is the audience on script deployments. Customer Center is the role your web store shoppers and customer portal users log in with. If a Suitelet or RESTlet has that role in its audience, anyone who can create a web store account can reach it.

A lot of those didn’t come from your developers. NetSuite’s own bundles have historically shipped with the default Customer Center role in the audience on their scripts. Sticky Notes is one. So even an account with no custom scripts can have Customer Center sitting on scripts that have nothing to do with customers.

What we check on every script deployment:

• Is Available Without Login checked? If so, does it need to be, and does the script check what it’s given before it does anything?
• What roles are in the audience? Is All Roles checked? Is Customer Center in there when it shouldn’t be?
• Does the script write files, create records or send email based on anything a user can type or pass in the URL?
• Who owns it, is it still used, and is it still deployed? Old scripts from a past consultant are the ones nobody’s looked at in years.

Bundles and SuiteApps get the same review. A bundle installed years ago for a feature you don’t use anymore is still running whatever it deploys.

Integrations and their roles

Every integration logs in as something. We list every integration record and every access token, and check what role each one uses.

It’s common to find an integration running as Administrator because that was the fastest way to get it working at setup. An integration should have a role that can do exactly what it needs and nothing else. If one of those tokens leaks, the role is what decides how bad it is.

Tokens for integrations you don’t use anymore get revoked. Integration records for vendors you’ve left get disabled.

Payment processing

If you take cards through CyberSource or another gateway, we look at who can see and change the payment processing profiles, whether the gateway credentials are current, and whether anybody who’s left the company still has access to the gateway’s own portal.

Web stores also attract card testing, where somebody runs stolen card numbers through small orders to see which ones work. If your web store takes cards, it’s worth asking your gateway what fraud rules you have turned on.

Features you don’t use

Every feature you have turned on is something that can be used. Sticky Notes is the example we hit most, because its scripts come deployed to Customer Center. If nobody in the company uses them, turn the feature off. Same goes for anything else sitting enabled from an old implementation.

Logging in: SSO, passkeys and minimal roles

If you’re on Google Workspace, NetSuite supports single sign-on through it. Your people log in with their Google account, and the Google side is where you enforce the strong login. When somebody leaves, you shut off their Google account and NetSuite goes with it.

As of 2026.2, NetSuite also accepts a passkey as the second factor in two-factor authentication. That includes Windows Hello, Face ID and Touch ID, and hardware security keys like a YubiKey. A hardware key is the strongest option here because there’s no code to phish. It has to be physically plugged in. Users set it up under Home > Settings > Manage Passkeys. NetSuite will still ask for the authenticator app code every three months as a fallback.

Then roles. Every login role should have the least access that person needs to do their job. Administrator should be two people, not ten. We go through every role with access, what it can do, and who has it.

Knowing when it happens

Our client found out from a flood of lockout emails, after their people were already locked out. Set up the alert before you need it, so the first sign of trouble is a text and not a phone call from somebody who can’t get in.

NetSuite keeps a login audit trail, including failed attempts. The screen won’t say why a login failed, but the audit trail does. A saved search on it shows whether it was a wrong password, so you can tell somebody guessing at your real users from a typo. We build a scheduled check against it that looks for a run of failed logins, logins from somewhere new, or a role you don’t expect logging in, and sends an alert. Email is fine for most things. For a lockout attack, the alert should go to a phone by text so somebody sees it at 6am.

What’s in the review

Our starting package covers:

• Every script deployment, with Suitelets and RESTlets first: public access, audiences, what they write
• Bundles and SuiteApps you have installed
• Every integration and token, and the role behind it
• Login roles and who has Administrator
• Features turned on that you don’t use
• Files in the File Cabinet created by anyone or anything unexpected
• Payment gateway access and settings
• Single sign-on with Google Workspace and passkeys or hardware keys for 2FA
• A login alert that goes to email and text

You get a written list of what we found, what we fixed and what’s still open. The starting package runs $1,000 to $2,000 depending on how many scripts and integrations are in the account.

Want to talk?

It’s a lot cheaper to do this before an attack than after one. If you’re not sure where you stand, the first hour is free. We’ll look at it with you, in your account, and send notes afterward whether you hire us or not. See our NetSuite Security program, or Book a free hour.

Author: Renee Chandler, Fourth Wave Consulting.