MFA for Domino 1.5.0 Brings Clearer Enrollment Stronger Security and a Lighter Engine

Security work is rarely one dramatic switch. More often, it is a steady habit: review the code, listen to users, remove friction, fix the small failures, and keep the moving parts current before they become a problem.

That is the spirit of MFA for Domino 1.5.0. This release is not about a single headline feature. It is a hygiene release in the best sense of the word. It tightens security, improves enrollment, makes authenticator setup easier, reduces the weight of the rendering engine, and fixes several cases where the product did not communicate clearly enough with users or administrators.

At Prominic, keeping applications current is part of the security model. Waiting until something breaks or until a customer is blocked is not a good maintenance strategy. A regular release cadence gives the team room to inspect areas that are working, not only the areas already under active development.

The other half of that cadence is feedback. Several of the changes in 1.5.0 came from people using the product and pointing out where something felt unclear, slow, or silent. That kind of feedback is valuable because authentication tools live in moments where clarity matters. A login flow should not make users guess. A recovery process should not hide the next step. A security control should not fail quietly.

Enrollment is now easier to follow

Enrollment is one of the most important parts of any MFA rollout. It is also one of the easiest places to lose users.

A user may understand why multi-factor authentication matters, but that does not mean they know where they are in the setup process. If a wizard gives no sense of length or progress, people start asking basic questions:

• How many steps are left?

• Did the last step save?

• Am I almost finished?

• What happens if I close this page?

  
  

In MFA for Domino 1.5.0, the four-step setup wizard now includes a numbered progress indicator. Completed steps show a tick, the current step is highlighted, and the step name appears clearly underneath.

That sounds small, but it changes the feel of enrollment. Instead of moving through a blank sequence of screens, the user can see the path. They know what has been completed and what still needs attention.

For admins and helpdesk teams, that also makes support easier. A user can say, “I am on step three,” instead of trying to describe a page from memory. That saves time during rollout, especially when many people enroll during the same week.

The release also improves several details around the same flow.

The phone field now starts on the correct country. That removes a needless early correction for users who are simply trying to enter a phone number and move on.

Rejected passwords now explain the specific rule that failed. A generic failure message forces users to guess. A specific one lets them fix the issue. If a password needs a certain length, character type, or format, the interface should say so.

The end of enrollment and the end of password recovery now offer proper buttons instead of links buried in a sentence. That gives users a clear final action and avoids the common problem of people missing a link because it is visually treated like body text.

These are not flashy changes, but they are the kind that shape trust. A login and enrollment system should feel deliberate. Users should see where they are, what happened, and what to do next.

Authenticator setup takes one less click

Authenticator apps are a common MFA method because they are familiar, widely supported, and do not depend on SMS delivery. Still, the setup experience matters.

In earlier versions, setting up an authenticator app required an extra click to reach the QR code. In 1.5.0, the QR code now appears directly on the user’s profile page.

That removes one step from the setup path. It also puts the most important enrollment artifact where the user expects to find it: on the profile page tied to their account.

This change helps in common real-world cases. Someone may be enrolling quickly between tasks. Someone else may be following helpdesk instructions over the phone. A clearer profile page makes both experiences smoother.

There is also an important accessibility and device-context improvement. Not everyone can scan a QR code.

A user might be viewing the profile page on the same phone where the authenticator app is installed. In that case, scanning the screen is not practical. Another user may rely on a screen reader. Someone else may have a camera issue or a damaged screen.

For those cases, the profile page now includes a “Can’t scan the code?” option. It reveals the setup key as text and includes a copy button.

That gives users a second path without making them contact support. The QR code remains convenient for most people, while the text key supports users who need or prefer a manual setup route.

Good MFA design should not assume that every user has the same device setup, vision, or workflow. This update makes authenticator enrollment more flexible without adding complexity for users who can scan the code normally.

Security enforcement is stricter where it should be

For this release, the team reviewed the codebase broadly, not only the parts already being changed. That matters.

Security issues often appear at the edges of a feature: a return value that says too much, an input field that accepts more than it should, or an output path that does not encode data consistently. Looking only at the code touched for a new feature can miss those older paths.

The 1.5.0 review covered the areas that matter most in an authentication product:

• Input handling

• Output encoding

• Session handling

• Cookie handling

• Authentication routes

• Responses that could expose more information than needed

  
  

The team specifically looked for injection and XSS-class issues, along with places where the application could return more data than it should. Everything found during that pass has been addressed in this release.

This is the kind of work that should be routine for software connected to identity. Multi-factor authentication is a security layer, but it is still software. It needs the same review discipline as any other internet-facing application, perhaps more.

Authentication routes deserve special attention because they sit between the user and the protected environment. Session and cookie handling deserve the same care because they affect what happens after a user proves identity. Output encoding matters because a security product should never become a channel for script execution or unsafe rendering.

The value here is not only in any single fix. The value is in the practice: revisiting the foundations, checking assumptions, and closing issues before they become operational problems.

For Domino environments reachable from the internet, that practice is especially important. Password-only access creates a clear gap. MFA reduces the risk from stolen, reused, or guessed passwords. A release like this one strengthens the layer that helps close that gap.

The engine is much lighter under the hood

MFA for Domino 1.5.0 also changes the template engine. The previous engine, FreeMarker, was 1.85 MB. The new engine, jMustache, is only 84 KB.

On many platforms, that difference would be useful but not very dramatic. On Domino, it matters more because of how customer servers handle files and caching.

Customer servers do not allow files on the filesystem, so nothing can be cached between agent runs. That means the weight of the engine becomes a cost paid on every page render.

And in this product, every page render includes places that matter to login.

A lighter engine reduces that repeated load. It is a practical change aimed at the way Domino actually runs, rather than a generic software preference.

This is the kind of performance work that is easy to overlook. Users may not know which template engine is running behind the page. Administrators may not care about the library name. What matters is that the application carries less weight each time it needs to produce a page.

The size difference is clear:

Component	Previous	New
Template engine	FreeMarker, 1.85 MB	jMustache, 84 KB

The change also fits the release theme. Version 1.5.0 removes unnecessary friction in the UI, removes unnecessary ambiguity in messages, and removes unnecessary weight in the rendering path.

Smaller is not always automatically better, but in this case the smaller dependency fits the platform and the workload.

Silent failures now speak up

One of the most frustrating issues in any security workflow is a silent failure. If something fails and the product reports success, both the user and the administrator lose time. Worse, they may build a false sense of completion around something that did not happen.

MFA for Domino 1.5.0 fixes three of these cases.

A code that failed to send no longer reports success. That is critical because delivery is part of the authentication or recovery path. If the code does not arrive, the interface needs to reflect that reality.

The enrolled push device list no longer appears empty when devices exist. Device visibility matters for account management. Users and administrators need to know what is enrolled so they can confirm, remove, or troubleshoot devices.

The password-recovery lockout no longer displays nothing. A blank state in a lockout scenario is especially poor because the user is already blocked. A clear message gives them context and helps support staff understand what happened.

These fixes are small in scope but large in effect. Authentication software should be honest about state. If something worked, say it worked. If something failed, say it failed. If something is locked, explain that it is locked.

Clear feedback also reduces unnecessary tickets. A user who sees a meaningful error is more likely to correct the issue or give support the right information. A user who sees a blank screen or false success message has nowhere to start.

What this release adds up to

Taken together, 1.5.0 improves four areas:

Security is tighter

The codebase received a broad review across input, output, sessions, cookies, and authentication routes. Issues found in that pass have been addressed.

New features are easier to reach

The authenticator QR code is now on the profile page, and users who cannot scan it can reveal and copy the setup key.

The UI and UX are clearer

The enrollment wizard now shows progress, password errors are more specific, country selection starts correctly, and final actions use proper buttons.

Small bugs are fixed

Silent failures now report more accurately, push device lists behave correctly, and password-recovery lockout states are visible.

This is why “hygiene release” should be treated as a compliment. Good security products improve through steady care. They get clearer, stricter, lighter, and more predictable.

Getting MFA for Domino 1.5.0

If MFA for Domino is already running in your environment, the upgrade is straightforward for most customers. The changes above are the main points to know before moving to 1.5.0.

Many customers handle the upgrade themselves in an afternoon. If you would rather have Prominic run it with you, or run it for you, email Support@Prominic.NET to book a window.

If MFA is not yet in place and your Domino servers are reachable from the internet, password-only access is a gap worth closing soon. Email Sales@Prominic.NET to talk through what a rollout would look like for your setup, including user count, MFA methods, and what the helpdesk should expect during week one.

You can also visit the product page at dominomfa.com for more information.

MFA for Domino 1.5.0 is a practical release: clearer enrollment, better authenticator setup, stricter security review, a lighter engine, and fewer silent failures. That combination makes the product easier to use and better aligned with the security work it is meant to support.