Setting up single sign-on

The setup wizard is in your dashboard. Keep this guide open for field-by-field instructions and troubleshooting.

You need a workspace plan with more than one seat. Only a workspace manager can set up single sign-on.

If you only need automatic joining

Want teammates to join your workspace automatically with their Microsoft work accounts? Enable Microsoft auto-join in workspace settings. For a dedicated sign-in link and sign-in restricted to your organisation, follow the SSO setup below.

What single sign-on does

With SSO, your team signs in to Guard.ch through Microsoft. Here is how it works:

1. A colleague opens your workspace's sign-in link, something like guard.ch/sso?workspace=acme.
2. Guard.ch redirects them to Microsoft. They sign in with their work account unless they are already signed in.
3. Microsoft confirms to Guard.ch who they are, and they land in your workspace, signed in.

A Microsoft password is entered only on Microsoft’s sign-in page. Guard.ch receives the details it needs to sign the person in and associate them with the workspace, including their name, email address and organisation identifier.

Before you start

Works with

Microsoft Entra ID, the sign-in service of Microsoft 365

On the Guard.ch side

A plan with more than one user, and the workspace manager role

On the Microsoft side

Permission to register applications, typically an IT administrator

Time

About ten minutes, plus a test run

Cost

None. Registering an app is included in every Microsoft plan.

Set up the Guard.ch side in your workspace settings, under Advanced options and Single sign-on. Keep this guide open alongside the wizard. The four numbered sections follow its steps.

Step 1: name your sign-in link

Your sign-in name appears after workspace= in the link, for example guard.ch/sso?workspace=acme. It must be 3 to 50 characters long and may contain only lowercase letters, numbers and hyphens. It cannot begin or end with a hyphen. If the name is already taken or reserved, choose another.

Your company name is usually the right choice. Enter it and save; the wizard reserves the name and shows the finished link with a copy button.

Step 2: register Guard.ch in Microsoft Entra

Register Guard.ch as an application for your organisation in the Microsoft Entra admin center. The dashboard wizard opens the right page; these are the steps in detail.

1. In App registrations (the admin center lists it under Entra ID), choose New registration and give the app a name your team will recognise, for example Guard.ch sign-in. The name is purely cosmetic; it appears in your own admin lists and in consent prompts, nowhere else.
2. Under Supported account types, pick Single tenant only, the single-company option: only accounts in your own organisation can use this sign-in. Older portals call the same option Accounts in this organizational directory only.
3. Select Register. Microsoft creates the app and opens its Overview page. You will return here in step 3.
4. Open the app's Authentication page, choose Add redirect URI, pick the platform Web, and paste your sign-in link exactly as the wizard shows it, for example https://guard.ch/sso?workspace=acme. Confirm with Configure. (Older portals offer the same Redirect URI field directly on the registration form.)
5. Open API permissions once, only to confirm there is nothing to do: the defaults already cover the only things Guard.ch reads, a person's name and email address. You add no permission and grant no admin consent, and Guard.ch cannot see mail, files, calendars or anything else.

Step 3: enter the three values in Guard.ch

Guard.ch now needs to know which directory and which app it is talking to, plus a way to prove itself: three values. The first two sit together on the app's Overview page in Microsoft, the Directory (tenant) ID and the Application (client) ID. Copy each into its matching field in the wizard.

The client secret

The third value is the client secret, which Guard.ch uses to identify itself to Microsoft as the registered app. In the app, open Certificates & secrets, choose New client secret, add a description and expiry, then confirm. Pay attention to these points:

• Copy the secret from the Value column, not the Secret ID. The value is the actual secret; the ID next to it is merely its label. Pasting the ID is the most common mistake in this step, and the connection test will report it as an invalid secret.
• Copy it immediately. Microsoft shows the value exactly once. Leave the page and it is hidden forever. If that happens, no harm done: create a new secret and copy that one.
• It expires. You choose how long it lasts when you create it, up to 24 months. Set a reminder before it expires; the Maintenance section explains how to renew it.

Paste the secret into the wizard and save. Guard.ch encrypts it before storing it and never displays it again, not even to you: when you edit the configuration later, an empty secret field means keep the one you have.

Optional settings

Email domain

The email domain is optional. If everyone on the team uses the same domain, enter it, for example acme.com. Microsoft may then skip its account picker, and Guard.ch can offer SSO when someone enters a matching email address. If the team uses several domains, leave it blank; the sign-in link still works.

Create accounts automatically

This toggle decides what happens when someone from your organisation opens the link for the first time. When it is on (the default), Guard.ch creates an account and adds the person to the workspace, using a seat. You can then share the link so teammates can join themselves.

With the toggle off, only people who already have a Guard.ch account in your workspace can sign in through the link. Others see an account-not-found message. Use this setting to allocate seats yourself.

Step 4, optional: limit who can sign in

Out of the box, anyone with an account in your directory can use the link (each newcomer still needs a free seat). To limit Guard.ch to a security team or a named few, restrict it on the Microsoft side, in the same admin center:

1. Go to Entra ID › Enterprise apps (older admin centers list it under Identity › Applications › Enterprise applications) and open the app you registered; it carries the same name.
2. On the Properties tab, switch Assignment required? to Yes and save.
3. On Users and groups, choose Add user/group and assign the people, or the group, who should have access.

Testing the setup

Use Test connection to check whether the directory, app and secret are valid at Microsoft. No one signs in during this test. If it fails, the error points to what needs fixing:

• Invalid Tenant ID. Microsoft has no directory under that ID. Re-copy the Directory (tenant) ID from the app's Overview page; it is easy to grab a neighbouring value by accident.
• Invalid Client ID. The directory exists, but no app with that ID lives in it. Re-copy the Application (client) ID, and make sure the app was registered in the same directory your tenant ID points to.
• Invalid Client Secret. Check that you pasted the Value, not the Secret ID. If needed, create a new secret under Certificates & secrets and copy its Value.
• Client Secret has expired. The secret's lifetime ran out. Create a new one and paste it into the wizard; everything else stays as it is.
• Could not connect to Azure AD. Guard.ch could not reach Microsoft at all. Usually a hiccup that passes on retry; if it persists, double-check the tenant ID, because a malformed one produces the same symptom.

When the test passes, check the full sign-in flow: open your link in a private window and sign in with your work account. A private window lets you see steps that a browser already signed in to Microsoft might skip. If you reach the dashboard, ask a teammate to try the link before you share it with everyone.

Deploying to the team

Share the sign-in link through your intranet, team chat or a managed bookmark. Anyone who opens it signs in through Microsoft and reaches the workspace.

On managed devices, IT can distribute your workspace sign-in name with the Guard.ch browser extension. If a Microsoft session is already active, sign-in usually needs no further input. If Microsoft requires interaction, such as multi-factor authentication, the normal sign-in page appears.

Every member uses a seat on your plan, however they joined. You can see and manage who occupies those seats in your workspace settings.

Troubleshooting

Sign-in errors appear either on the Guard.ch sign-in page or on a Microsoft page with an AADSTS code. Both types are covered here.

Messages from Guard.ch

“SSO is not available.” The address does not lead to an active SSO setup. Three causes cover almost every case: a typo in the link (or an old bookmark from before a rename), the SSO configuration was removed, or the workspace no longer sits on a multi-user plan.

“SSO for this workspace is not fully configured yet.” The setup was started, the link name exists, but the Microsoft credentials were never saved. Whoever manages the workspace needs to finish step 3.

“Your account was not found.” Automatic account creation is switched off and this person has no Guard.ch account in the workspace yet. Either add them first, or switch Create accounts automatically on.

“Workspace is at maximum capacity.” The sign-in itself succeeded, but every seat is taken, so there was no room to add the newcomer. Free a seat by removing a member, or upgrade the plan, and have the person simply sign in again.

“This user already belongs to another workspace.” A Guard.ch account can only be a member of one workspace at a time, and an account with this email already belongs to a different one. The person leaves that workspace first (or its manager removes them); after that the sign-in goes through.

“Your account has been disabled.” The account was blocked on the Guard.ch side. This is not an SSO problem; contact support.

“Microsoft authentication failed.” The sign-in attempt was interrupted, often because an earlier attempt is still open in another tab. Close that tab and open the sign-in link again. If the error persists, check whether your browser blocks all site data; the sign-in flow needs a one-time security token in the tab.

Error codes from Microsoft

AADSTS50011 Redirect URI mismatch. The address registered in step 2 does not exactly match your sign-in link. Open the app's Authentication page in the admin center and make the redirect URI character-for-character identical, including https and the workspace name. This is also the error you will meet after renaming your link without updating Microsoft.

AADSTS700016 Application not found. The directory has no app under your Application (client) ID. Either the ID was copied wrongly, or the app was registered in a different directory than your Directory (tenant) ID points to. Compare both values against the app's Overview page.

AADSTS7000215 Invalid client secret. The stored secret is wrong or expired, often because the Secret ID was pasted instead of the Value. Create a new secret and save its value in step 3 of the wizard.

AADSTS50105 User not assigned. Assignment required is switched to Yes and this person is not on the list. Add them, or their group, under Users and groups in the enterprise application.

AADSTS90094 Need admin approval. Sometimes worded Approval required. Your organisation requires administrator consent even for basic sign-in permissions. An administrator opens the app under Enterprise applications and grants consent for the organisation once; after that the prompt disappears for everyone.

Maintenance

After setup, these four situations are the ones to watch for:

The secret expires

When the secret expires, new SSO sign-ins fail. Create a new client secret under Certificates & secrets in Microsoft. Then open the SSO settings in your dashboard, enter the new value and save. Existing sessions stay signed in.

Someone leaves the company

Disable the person’s Microsoft account so they can no longer sign in through SSO. Then remove them from your workspace members list to free their seat.

The link needs to change

If the workspace sign-in name changes, update it in step 1 of the SSO settings and change the redirect URI in the Microsoft app to match. Then tell your team and update managed bookmarks.

Turning SSO off

If you remove the SSO configuration, the link stops working immediately. Accounts, memberships and past investigations remain. Your team can use another sign-in method, and you can set up SSO again at any time.

Security

• Passwords never touch Guard.ch. They are entered on Microsoft's own page, if they are entered at all.
• Guard.ch receives a person's name and email address, and nothing else. No mail, no files, no calendar.
• The client secret is encrypted before storage and can be written but never read back out, not even by you.
• Every sign-in round trip carries a signed one-time token, so a forged or replayed attempt is rejected.
• Your Microsoft policies still apply to Guard.ch, including multi-factor authentication, device rules and conditional access, just as they do to other company apps.

Set up single sign-on

Open the wizard in your workspace settings and follow the four steps above. Keep this guide handy for troubleshooting and later changes.