Will it change the current end user experience after the upgrade?

Hi ​@JoyceMannam,
The user experience will remain the same.

Regards,

John

We have several Nintex-related enterprise applications in our tenant, but based on sign-in logs, the most active one appears to be “Nintex Identity Platform.” However, under Single Sign-On, it's configured for OIDC (OpenID Connect) — not SAML.

In contrast, the Nintex documentation and instructional video clearly reference a SAML-based configuration (with Entity ID, Reply URL, etc.), which doesn’t align with what we’re seeing.

Does this SSO upgrade only apply to SAML identifiers?
 

+1 Looking at Nintex Identity Platform we are using OIDC not SAML - very confused since we cannot follow the video or the documentation - will raise with Nintex support this end

Hi ​@MochAlex and ​@GeoffE1E6,

This is correct, the upgrade is focused on SAML federated customers at this time. If you saw a pop-up asking you to upgrade and you are OIDC (or WAAD) federated you do not need to perform the upgrade. We will exclude non-SAML customers from our next round of notifications. Apologies for any inconvenience caused.

Thanks for being proactive and reviewing the announcements and pop-ups!

Regards,

John

Hello,

Just to confirm. If we have Azure Active Directory listed as the provider in our Identity federation section of Settings/User management, there is no action we need to take. There is only action required if we see SAML as the Provider?

Thank you,

Michele

Hi ​@Michele,

That is correct. If you have Azure Active Directory listed as the provider in identity federation you are WAAD federated and do not need to take action. All other providers are SAML federated.

Regards,

John

​@JohnWieland - Thanks for the quick response!

Thanks ​@JohnWieland : The related Video helped me to implement the change in one Go!
Well Done! 😎

Great to hear that ​@RonLevy. Thanks!

We are excited to announce a significant upgrade to our Single Sign-On (SSO) implementation. We will transition from a third-party vendor to an internally managed service for SSO. This change is designed to enhance your experience by offering improved stability, performance, and flexibility.

Why are we making this change?

By bringing SSO in-house, we can:

• Ensure Greater Stability: Control over the service allows us to address issues more quickly and ensure consistent uptime.

• Enhance Performance: Optimized architecture tailored to Nintex’s environment reduces latency and ensures seamless user experiences.

• Increase Flexibility: An internal service allows us to respond more effectively to customer needs and implement feature updates at a faster pace.

Additionally, the current third-party solution will reach its end of life in November 2025. This transition not only brings improvements but also ensures continuity and security for your authentication processes.

What do I need to do?

SAML federated customers will need to perform a simple upgrade by changing some values in their Identity Provider. If you need to upgrade you will see a banner on your User Management page under settings:

If you select the the ‘...’ beside your identity federation configuration you will see the option to ‘upgrade’ as shown below:

The upgrade process will guide you through the rest of the process where you’ll update the entity ID and ACS URL in your identity provider. You can also view a video demonstration of the upgrade here.

When do I need to do it by?

The current SSO solution will be retired on the 30th of November 2025. We encourage all customers to begin planning their upgrade to the new SSO service as soon as possible. Customers that have not upgraded by the 30th of November 2025 will be unfederated and fall back to OTP.

How can I get help if I need it?

If you require assistance or have any concerns, please contact Nintex support or your Nintex account manager.

Conclusion

This upgrade is a significant milestone in our journey to provide you with the best possible experience. By transitioning to an internally managed SSO service, we’re ensuring that your authentication processes are more stable, efficient, and adaptable than ever before.

We have SAML w/ADD identify federation. This includes “guest” accounts. Can you (or someone) confirm the below items as it relates to this upgrade? 

• Guest and members in azure will still have the ability to access NAC tenants via SSO. 
• Authenticated tasks will not be impacted for members or guests - they will still be considered authenticated for members and guests. 
• Onboarding will still automatically add users as a “participants” to the user management section in settings upon visiting one of our tenants. 

Hi ​@brandiwoodson,

Can I check if you are federated with WAAD, or with SAML? When you say SAML w/ADD it kind of sounds like you might be WAAD federated.

One way to check is on the User Management page, if it says “Azure Active Directory” under your Identity Federation page, you are WAAD federated and do not need to upgrade to SAML at this time unless you want to.

Let me know if you have any other questions.

Regards,

John

Hi ​@brandiwoodson,

Can I check if you are federated with WAAD, or with SAML? When you say SAML w/ADD it kind of sounds like you might be WAAD federated.

One way to check is on the User Management page, if it says “Azure Active Directory” under your Identity Federation page, you are WAAD federated and do not need to upgrade to SAML at this time unless you want to.

Let me know if you have any other questions.

 

Regards,

John

Thanks. Says SAML for provider.

Hi ​@brandiwoodson,

Okay, you will need to upgrade.

Answers to your questions are as follows:

We have SAML w/ADD identify federation. This includes “guest” accounts. Can you (or someone) confirm the below items as it relates to this upgrade?

• Guest and members in azure will still have the ability to access NAC tenants via SSO. Yes
• Authenticated tasks will not be impacted for members or guests - they will still be considered authenticated for members and guests. Yes
• Onboarding will still automatically add users as a “participants” to the user management section in settings upon visiting one of our tenants. Yes

Regards,

John

This only needs to be configured in one of our NAC tenants correct? We have alot!

That’s correct ​@brandiwoodson. You should only need to do it in one of your tenants for the organization.

Thanks, went through the upgrade process. I do appreciate the fact that if you have multiple tenancies, you only need to do it for 1 and it will apply to all under the organisation they are associated with. Mapping was a tad difficult to do with F5 SAML. Later we changed to another SAML authentication method which was way simpler and easier overall to linkup. 

Great news Callan. Are you able to expand on the difficulties with mappings in F5 SAML?

We also have support for multiple SSO connections, and per-tenant SSO connections in the pipeline, if you are interested in chatting more about it you can book a time here.

Appreciate that JohnWieland. The mapping issues we resolved internally by bruteforce manhandling the xml file to resolve after a few iterative attempts + Support Tickets to assist us.

That was when we first setup the tenancies back in Dec 2024.

When we conducted the upgrade as per system requirements, back in July 2025.

1 thing I found with the upgrade was it was not liking it when I clicked ‘Upgrade’ to proceed as we kept running into an issue. After a few attempts, with Support help, I decided to delete the SAML IdP we had in place and start again with the same F5 files. This worked upon doing this action straight away. Most likely a cache issue or F5 ‘other’ SAML config related and either the IdP or Nintex did not like it. 

Moving to the other SAML auth however resolved all of that and was way easier to set up- Entra ID. We completed that within 10min without issue and we used the Nintex guides to ensure we followed process and understood the how to.

Will users be prompted to log in again the next time they go to NAC after the SSO upgrade? I’m trying to understand what the expected behavior will be for end users starting a workflow or checking on their tasks in the dashboard.

Thanks,

Dan

Hi Dan, yes they likely will. It also depends on the IdP having it a mandatory setting to force login each time a user opens the application from a fresh browser / timeout. I believe some IdP’s in Nintex can also permit a fast logon, where it will not request a user to re-logon if they have done so already. But that setting may not appear. I had it for SAML F5, but not for Entra ID. Might be another setting the federated identity provided may permit/allow. Depending upon your cyber security risk appetite these things need discussion and agreement. We opted for logon each time, that way it is forced irrespectively to ensure a tighter cyber security protocol. 

Thanks ​@Callan.Applebee. ​@dan_white Callan’s answer is correct, it depends on the IdP and we also believe it depends on if you update an existing application/configuration in your IdP with the new entity ID and ACS URL, or if you create a new application/configuration. It’s more likely to require the user to login again if you create a new app/config than if you use an existing one. If you have concerns please reach out to your AM or CSM.

Hi,

Is this likely to cause any downtime/unavailability in Nintex? Planning this in, and would like to know if it needs to be done after hours.

Thanks,
Dannielle

Hi Danielle,

While it’s very unlikely that you encounter an issue, it can still happen if you make an error copying the entity ID and ACS URL. I recommend you do it after hours and be aware of how to login via OTP (go to <your tenant>.workflowcloud.com/otp).

If possible, you should also update your existing configuration in your identity provider, rather than create a new one. If you encounter any problems please contact support.

Regards,

John