Challenges in scaling MFA for large organizations include user hesitation as well as high technical and operational overheads.
Users often think of MFA as an inconvenience, but this is amplified in organizations since the data mostly belongs to the organization (not them), and even more so in large organizations where security is typically tighter, more time-consuming, and ultimately more disruptive to their workflow. In short, users consider organization-based MFA a burden with little reward to them personally, and so might not use it if it’s optional or try to hack their way around it if it’s required.
The trick is to find the right balance between security and UX.
A major technical challenge with scaling MFA for large organizations is catering to older devices with inadequate hardware or software features when users use their personal devices for organizational security. Some organizations provide free, limited-access devices to their employees for this reason, but if your B2B product incorporates MFA, you can’t rely on your customer doing this for their employees.
In any case, you’ll need to optimize MFA for whatever’s considered a low-end device at the time (e.g., by sending one-time passwords) while promoting more secure MFA methods (e.g., a combination of a security key or passkey and a biometric) to those that have access to them. This means that you’ll need to implement additional MFA methods, but also detect which methods are available to users on a case-by-case basis.
In addition, organizations themselves can lack the right hardware or software needed to implement MFA effectively and securely, particularly when integrating with legacy or custom-built systems. As a product team, this can mean working with customers (especially enterprise-level customers) to get their MFA setup up to standard, which can be difficult and time-consuming.
Finally, as you can imagine, a lack of clear documentation, quality training, and customer support can make the setup and usage of MFA difficult for customers (especially those that are less tech-savvy), which means that you’d need to allocate more resources to customer support or risk customer churn, either of which is likely to result in a loss of revenue either way. Even the handling of account lockouts and lost devices, which should be the responsibility of the customer and their employees, can pose a significant burden on you as the product owner, should they seek your help. Therefore, you must provide technical (but user-friendly) documentation, training, and customer support.
Technical documentation, training, and customer support, contrary to the point of reducing operational overheads, should be an iterative, ongoing process. This applies even more so to the technical documentation aspect, where, as your product changes, so should the technical documentation that explains how to use it. This should become part of the day-to-day for a product team so that a day-to-day where you’re constantly putting out fires never happens.
In addition, there are often a number of laws and regulations that businesses must adhere to (e.g., data privacy laws, industry-specific laws such as HIPAA, and specialized niche standards such as COPPA). To add to this, there may also be some voluntary best practices (e.g., SOC 2, a security best practice) that realistically you must comply with in order to remain competitive in your market.
Some requirements will apply to you as a product owner, but if your customers have their own customers, you might need to ensure that they can comply, too. Finally, requirements like these are constantly evolving, so you must stay up to date with them, audit your product and business practices at appropriate intervals, and maintain policy enforcement in accordance with any laws, regulations, and recommended best practices that apply to your business.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Designing for background jobs means designing for uncertainty. Learn how to expose job states, communicate progress meaningfully, handle mixed outcomes, and test async workflows under real-world conditions.
There’s no universally “best” design language. This section breaks down when Linear-style design works well, how to build beyond it (or start from Radix UI), why it felt overused in SaaS marketing, and why conversion claims still need real testing.
Minimal doesn’t always mean usable. This comparison shows how Linear-style UI keeps contrast, affordances, and structure intact, unlike brutalism’s extremes or neumorphism’s low-clarity depth effects.
Linear-style UIs look simple, but the theming system has to do real work. Here’s how to meet WCAG 2.2 contrast requirements across light, dark, and high-contrast modes — whether you’re using a UI library or rolling your own tokens.
Learn more →
