Multi-Factor Authentication (MFA) – Part 2: Why It Needs to Cover Every Account

NetSuite MFA: Recap of Part 1

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.

NetSuite MFA: Why You Must Cover All Accounts

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.

NetSuite MFA: The Problem with Exceptions

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.

NetSuite MFA: Compliance Coverage

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.

NetSuite MFA: The Top-Priority Risk

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.

NetSuite MFA: Recommended Controls

Making MFA universal isn’t just about turning it on—it’s about keeping it on. Here’s what strong MFA governance looks like:

• Enforce MFA for all roles in your NetSuite environment so that every role assigned to a user requires it.
• Inventory Exceptions for approved roles, such as web service only roles, and ensure they are secured with an API key or token-based authentication wherever possible.
• Monitor MFA Configurations Regularly to ensure no roles have been quietly stripped of the MFA requirement. In many systems, this can be done through audit logs that track configuration changes—but unfortunately, NetSuite does not provide native logging for changes made on the Two-Factor Authentication Roles page. For NetSuite, the only way to achieve this level of oversight is to implement a custom auditing solution. Without it, changes to MFA requirements on roles could go undetected, creating hidden security gaps
• Quarterly certification of MFA coverage—Because there is no way to manage via audit logs and alerts in NetSuite, validate that every active role in the system still has MFA enabled and that there are no unauthorized exceptions.

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.

NetSuite MFA: What’s Coming In Part 3

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.