In Part 1, we broke down how MFA works in NetSuite, where it’s configured, and the supported methods. Now, let’s tackle the bigger question—why MFA should be universally applied to all roles, the problem with exceptions, and what controls keep you compliant and secure.
Every account in your ERP system, whether it’s an IT administrator, an accounts payable clerk, or a generic integration account, has the potential to become an entry point for attackers. Roles are often very overprovisioned which can result in attackers being able to commit fraud, change key system security and control settings, or steal sensitive information.
While privilege escalation is theoretically less likely without user and role provisioning access, overprovisioning often erases that safeguard. Permissions meant for specialized admin roles can creep into everyday accounts, creating hidden pathways to elevated access. This means even “low-risk” accounts can become launchpads for fraud or system compromise. The problem is compounded when organizations lack GRC compliance tools and a detailed sensitive access ruleset to quickly spot who can perform privileged actions like creating new users or assigning roles. When it comes to financial systems like NetSuite, selective MFA enforcement isn’t just a gap—it’s an open invitation for attackers to walk in through the easiest door.
Exceptions usually arise when an organization assumes a user account or role isn’t “high risk.” In the case of NetSuite, we’re talking about roles specifically—and that’s a dangerous assumption. ERP roles, especially standard or seeded roles provided by the vendor, are often overprovisioned, packing in far more capabilities than intended, sometimes even administrative-level functions. Without an all-in MFA policy, a seemingly low-risk role can slip through unnoticed, and for any user assigned to it, that role could become the exact credential an attacker needs to log in, pivot, and escalate. The consequences can include fraud, unauthorized configuration changes (including to critical security settings), sensitive data theft, and damaging audit findings tied to weak authentication controls. The takeaway is simple: treat every role as high risk and enforce MFA across the board. The minor inconvenience of entering a code that takes 30 seconds or less is a small price to pay to safeguard your organization from potentially catastrophic breaches.
Compliance frameworks like SOX and NIST 800-53 AC-7 are explicit—MFA should be required for privileged functions. In practice, that means all accounts that can access financial data, change configurations, or perform administrative actions should have MFA enabled. The simplest way to meet that requirement? Apply MFA to every role in the system.
From a controls standpoint, MFA provides greater assurance that the person logging in really is who they claim to be. For SOX, it’s a strong authentication control that helps secure systems tied to financial reporting. Under NIST 800-53 AC-7, it directly satisfies the requirement for multiple authentication factors when accessing privileged functions or remote systems.
Internal security policies should map to these same requirements, explicitly stating that MFA is required for all roles unless formally exempted through a documented approval process.
Here’s the nightmare scenario: stolen credentials + no MFA = full ERP takeover. That can lead to fraudulent transactions, mass data theft, or even a system-wide outage. In the age of phishing kits and credential dumps, the odds of someone attempting to log in with stolen credentials aren’t hypothetical—they’re pretty much guaranteed.
Making MFA universal isn’t just about turning it on—it’s about keeping it on. Here’s what strong MFA governance looks like:
In short, MFA’s value comes from its universality. If you leave gaps, attackers can find them. But when every end-user account that needs access to the UI has that second lock on the door, you’re not just meeting compliance requirements, you’re actively closing off one of the most common and dangerous attack paths into your NetSuite environment.
In Part 3, we’ll look at how today’s phishing tactics are exploiting accounts without MFA, real-world ERP breaches that could have been prevented, and the steps you can take to close those gaps before they’re targeted.