Security & Sign-On

Security & Sign-On

1. What it is

Security & Sign-On is where you set the rules for getting into your organization. You set password rules, require two-factor authentication, add single sign-on (SSO) providers, control how long sessions last, and review who signed in and how. Every way in follows the policies you set here: password, SSO, a one-time code or a magic link.

• Where: the Security section of the admin sidebar. Sign-in Policies and SSO Configuration need the Administrator role. Sessions & Tokens and Authentication Log appear only for a Super Admin.
• What it is not: clock-in security (kiosk PINs, IP checks on punches, offsite clock-in) is a separate set of attendance settings, not part of this page.

2. Standing it up

1. Go to Admin → Security → Sign-in Policies. Every new organization starts with sensible defaults already on. Password complexity is enforced. Super Admins and Administrators must use two-factor authentication. People are signed out after 60 minutes of inactivity.
2. Review Password Policies. By default a password needs at least 8 characters, with uppercase letters, lowercase letters and numbers. Special characters are not required. Tighten this if your compliance framework asks for more.
3. Review Two-Factor Authentication. Turn on Require Two-Factor Authentication for all users, or tick roles under Require only for specific roles. People in a required role who have not enrolled are sent to the setup screen at their next sign-in. They are not locked out.
4. If you use SSO, go to Admin → Security → SSO Configuration. SSO is included in every edition. Add a provider: Google Workspace, SAML, Microsoft Entra ID, MangoApps or OpenID Connect. Test it, then enable it. A new configuration is off until you tick Enable this configuration for login.
5. Check the session limits. Sign out after inactivity defaults to 60 minutes. Always sign out after defaults to 24 hours. If you run shifts, consider a daily sign-out time between shifts (see §5).

3. How it fits together

Sign-in Policies vs SSO Configuration. These are two separate pages that work together. Sign-in Policies set the rules for every way in: passwords, lockout, session length, two-factor and one-time codes. SSO Configuration manages the identity providers whose buttons appear on the login page. Someone who signs in through SSO is still signed out by your session limits.

Single sign-on providers. There are five provider types:

Provider	What it is
Google Workspace	Sign in with a Google account
SAML	Any SAML 2.0 identity provider, such as Okta, PingOne or ADFS
Microsoft Entra ID	Sign in with a Microsoft work account
MangoApps	Sign in with your MangoApps Hub account
OpenID Connect	Any OpenID Connect identity provider your organization runs

You can add several configurations of one type, for example two SAML providers for two divisions. Every enabled configuration appears as its own button on the login page. Client secrets are stored encrypted and never shown again.

System default vs custom configuration. For Google, SAML, Microsoft and MangoApps, MangoApps can supply a shared, ready-made configuration (the system default). You can use it, add your own custom configurations, or both. OpenID Connect is always your own: it is never offered as a system default, and it is only used for signing people in.

OpenID Connect presets. When you pick OpenID Connect, you choose an Identity provider: Okta, Ping Identity, Auth0, OneLogin or Other OpenID Connect provider. The preset only pre-fills the form and names the login button — for example, an Okta configuration shows as “Okta”. Every preset signs people in the same way.

Sign-in accounts (connecting your own Microsoft account). A person can connect their own Microsoft account to their profile. Your organization must have Microsoft Entra ID sign-in set up. They go to Account settings › Security, open Sign-in accounts, and click Connect Microsoft account. An administrator can’t link one person by hand. Two rules protect the person:

• An account your organization created shows Managed by your organization and can’t be disconnected there.
• Nobody can disconnect their only way in. They must set a password or get another way in first.

Confirm it’s you (step-up). Some actions ask a person to prove it is still them, even though they are signed in. Changing your own password or PIN is one. So is connecting or disconnecting a sign-in account. The person enters their current password or PIN, or clicks Confirm it’s you. That confirmation lasts 15 minutes. Someone who signs in with SSO can sign in to their provider again instead. If the provider can’t confirm a fresh sign-in, they get a one-time code. Without a confirmation, the new password or PIN is not saved and the page says why.

Worked example: an employee who signs in with Microsoft wants to set a PIN. They open the Security & Password card on their profile and click Confirm it’s you. They sign in to Microsoft again, enter the new PIN and save.

Two-factor authentication. Two-factor uses an authenticator app. People scan a QR code to enrol, get 10 one-time backup codes, and enter a 6-digit code at each sign-in. Service accounts are always exempt, because they cannot answer a challenge. Signing in with a one-time code skips two-factor, because the code is itself the second factor.

Session lifetime. Three limits apply, and whichever comes first ends the session:

• Inactivity: signs someone out after a period with no activity (default 60 minutes).
• Hours limit: signs them out after a fixed number of hours, however busy they are (default 24).
• Daily sign-out time: optional. Signs everyone out at one local time each day.

Account lockout. After too many failed sign-ins (default 5), the account is locked for 60 minutes. A completed password reset ends the lock early. Trying again while locked does not restart the clock. A locked account cannot use a one-time code either.

One-time code sign-in. People can sign in with a 6-digit code sent to their email or phone, instead of a password. It is on by default.

Authentication log. This is a record of every sign-in, sign-out, failed attempt and expired session. Each entry shows how the person signed in, their IP address, browser and portal. Entries cannot be edited or deleted. They are kept for 395 days by default.

4. Running it

Adding an SSO provider

1. Go to Admin → Security → SSO Configuration and click New Custom SSO Configuration.
2. Give it a Name and choose a Provider Type.
3. Enter the provider’s details:
   • SAML: choose Paste XML Metadata and paste your provider’s metadata. The sign-in URL and certificate are read from it automatically. Copy the service-provider values shown on the form into your identity provider.
   • Google Workspace: enter your OAuth client_id and client_secret in Provider Settings (Google OAuth JSON).
   • Microsoft Entra ID: enter the app registration’s client ID, client secret and directory (tenant) ID, as JSON, in the provider settings box.
   • OpenID Connect: pick the Identity provider, then fill in Issuer URL, Client ID and Client secret. Leave Scopes at openid profile email unless you map groups. Copy the Redirect URI into your provider. Also copy the Mobile app redirect URI if people use the mobile or desktop app.
4. Tick Enable this configuration for login and save.
5. Open the configuration and click Test Configuration. For OpenID Connect, the test checks your provider’s discovery document, sign-in endpoints and signing keys.
6. The SSO Configurations page previews the login page, showing exactly which SSO buttons people see right now.

For OpenID Connect, the Initiate login URI appears after you save. Paste it into your provider to let people start from its app tile, such as the Okta dashboard.

Choosing system or custom configurations

Click Settings on the SSO Configurations page. For each provider, switch it on or off and choose whether to Include System Default. You can also turn on automatic account creation. When it is on, anyone whose email is on your Allowed email domains list gets an account at their first SSO sign-in.

For Microsoft sign-in, that domain list also decides who is matched to an existing account by email. People who connected their own Microsoft account keep signing in either way.

Reviewing SSO logs

1. On the SSO Configurations page, open a configuration’s menu and click View Logs. Or open a configuration and click View all SSO logs.
2. Filter by Configuration, Status, From and To.
3. Each entry shows whether the attempt worked and which configuration it used. Use it to debug a misconfigured provider.

Checking NIST compliance

Sign-in Policies shows a NIST 800-63B (AAL2) badge. It is green when two things are true: inactivity is 60 minutes or less, and the hours limit is 24 or less. Otherwise it reads “Outside AAL2” and lists the settings responsible. You are shown the tradeoff, not blocked.

Signing people out or revoking API tokens

1. Go to Admin → Security → Sessions & Tokens (Super Admin only).
2. Find a person and click Sign out to end their sessions everywhere.
3. To sign out everyone, type your subdomain to confirm, then click Sign everyone out. Your own sessions are kept unless you tick Include my own sessions.
4. Click Revoke beside an API token to stop it at once. Any integration using it stops working.

Reviewing the authentication log

1. Go to Admin → Security → Authentication Log (Super Admin only).
2. Filter by event, outcome and date, or search by name, email or IP address.
3. Export to CSV for compliance evidence.

5. Settings

All of these are on Admin → Security → Sign-in Policies.

Setting	Default	What it changes
Require Two-Factor Authentication for all users	Off	Everyone must enrol in two-factor at their next sign-in
Require only for specific roles	Super Admin and Administrator ticked	Roles that must enrol even when the switch above is off
Enforce password complexity requirements	On	Whether the password rules below apply
Minimum password length	8	Fewest characters a password can have
Require uppercase / lowercase letters / numbers	All on	Character types a password must include
Require special characters	Off	Whether a password must include a symbol
Password expiration (days)	0 (never)	Days before a password must be changed
Maximum failed login attempts	5	Failed sign-ins before the account locks for 60 minutes
Sign out after inactivity (minutes)	Blank: 60 minutes	Minutes with no activity before sign-out
Always sign out after (hours)	Blank: 24 hours	Longest a session lasts, however active
Also sign everyone out every day at	Blank (off)	A local time each day when every session ends
Keep the authentication log for (days)	Blank: 395 days	How long sign-in records are kept
Allow Self-Registration	Off	Anyone with your registration link can create an account. There is no approval step: it is active at once
Enable OTP Login (Login with Code)	On	Whether people can sign in with a one-time code
Enforce IP address restrictions	Off	People can sign in with a password or a one-time code in a browser (computer or phone) only from IP addresses you allow, and the Office add-in and the MangoApps CLI can finish signing in only from them. Single sign-on and the native mobile app are not filtered. A refused sign-in appears in the authentication log

6. More help

• Security & Sign-On FAQ: exact limits and ranges, two-factor setup, SSO troubleshooting, and “why can’t I sign in” questions.
• Users, Roles & Permissions: who can access the platform and what they can do.
• Ask AI: the assistant answers questions about sign-in security from these articles.