LAFT can be integrated with Microsoft Azure AD for Single Sign-On (SSO). This allows all users to authenticate through Microsoft instead of having separate passwords or optional SSO logins.
When SSO is enabled, it applies to all users in the organization , including external users and suppliers who will have access to LAFT.

Overall process for activation

Step 1 - Internal clarification
Before you ask LAFT to activate SSO, the following should be clarified:

• All internal users exist in Azure AD.
• All external users/suppliers are added to Azure AD if they are to have continued access.
• Roles/accesses in LAFT are updated or planned.
• You have identified who manages Azure AD for you.

Step 2 - Prepare users (optional, but recommended)
Users can already log in with SSO by selecting "Log in with Microsoft" on LAFT's login page.
We recommend that you test this in advance to ensure that:

• The email address in LAFT = the email address in Azure AD
• Users log in without any problems

Step 3 - Importing new users
If you want LAFT to import users before SSO is activated:

• Use the Excel template for users ( download here )
• This includes your first name, last name, email, telephone number, and role in LAFT.
• Send the file to LAFT ( support@laft.io )

Step 4 - Let us know when you want to enable SSO
When you are ready, notify LAFT. We activate SSO, and the effect is immediate:

🔔 From the time of activation, all users must sign in via Microsoft. There is no overlap period.

Step 5 - Possible revert
If unforeseen problems arise, LAFT can quickly turn off “forced login” again.

User types and what you need to do

Internal users
These are normally already in Azure AD. You must:

• Confirm that email addresses in LAFT and Azure match
• Test that SSO works for a selection of users

Roles and levels
Roles in LAFT affect which features the user has access to. The role in LAFT is still managed in LAFT, not in Azure AD. When you send the Excel import file, each user must have the correct role assigned.

External users/suppliers
This point is critical. When SSO is enabled, Microsoft login applies to everyone , regardless of affiliation.
Therefore, you must:

• Add external users as Guest Users in Azure AD (or equivalent organizational routine)
• Ensure they are assigned the appropriate level of security in their Microsoft environment
• Possibly inform suppliers about the new login method

If external users are not located in Azure AD, they lose access from the moment SSO is enabled.

Challenges and things to watch out for

General challenges

• Different email address in LAFT and Azure AD → users cannot log in.
• External users are forgotten in the preparation. Lack of internal communication before activation.
• Users with multiple Microsoft accounts (work/personal) are experiencing confusion.
• Azure AD policies (MFA, Conditional Access, IP restrictions) may be blocking some users.

Technical dependence on Microsoft
When SSO is enabled, LAFT relies on:

• Azure AD is working as normal
• Their Microsoft policies allow login from external and internal users
• Any vendor agreements with Microsoft allow Guest access

Transition and change (phasing in/phasing out)

There is no overlap. Activation time = everyone must log in via Microsoft.

Recommended practices before activation:

• Ask users for a period of time to optionally sign in with “Sign in with Microsoft”
• Keep an eye on whether anyone can't log in.
• Fix errors in Azure AD before enabling forced SSO

Security, communication systems and supplier agreements

Security

• SSO strengthens security by consolidating authentication into Azure AD.
• MFA and conditional access are managed centrally by you.
• No passwords are stored in LAFT when SSO is on.

Communication system
Internally you should:

• Inform all employees about the change
• Inform all suppliers/externals
• Designate an internal contact to handle Azure AD questions from employees

Supplier agreements

• Check that your Microsoft license covers Guest Users
• Check any agreements with suppliers that require access to LAFT
• Update internal procedures for onboarding/offboarding employees - this will now be linked to Azure AD

Risk factors + solutions