Sign-in with Microsoft 365

PhishSpot integrates with Microsoft 365 (Entra ID) for end-user sign-in. Employees imported from your directory log in with their corporate Microsoft account — no separate password to manage, no separate identity to onboard. The first time they sign in, PhishSpot links their authenticated user to the existing contact record imported from Entra, and lands them on their personal training portal at /guest/dashboard.

This chapter covers the sign-in flow as it appears to employees, the personal portal they reach after signing in, and the dual-role picker shown to admins who are also end users.

24.1 Why Microsoft 365 SSO?

Three reasons:

• No extra password to lose. Employees use the same Entra account they already use for Outlook, Teams, SharePoint and the rest of Microsoft 365. There’s nothing new to forget.
• Automatic onboarding. Once Entra directory sync (Chapter 25) imports an employee, their first Microsoft sign-in turns the contact into a fully-formed user account — no admin intervention required.
• Inherited security posture. Conditional access, MFA, device compliance — every Entra policy you have already applies. PhishSpot doesn’t run its own MFA in front of an Entra-authenticated session because Microsoft already enforces it upstream.

24.2 Admin setup

The platform-wide OAuth app is already registered in PhishSpot’s tenant. To enable end-user sign-in from your tenant you only need to grant admin consent for the PhishSpot enterprise application and (optionally) connect directory sync:

1. Open Account settings → Integrations → Microsoft 365.
2. Click Connect Microsoft 365. You’ll be redirected to the Microsoft admin consent screen.
3. Grant the requested scopes (User.Read.All, Group.Read.All, Directory.Read.All for sync; openid, profile, email for sign-in).
4. Microsoft redirects you back. PhishSpot stores your tenant ID and a tenant-scoped app token.
5. (Optional but recommended) configure sync schedule — see Chapter 25 §25.3.

After admin consent, any user in your tenant whose email matches an imported Contact on your account can sign in. Users who don’t match a Contact (or whose tenant ID doesn’t match a configured integration) hit a friendly “no access” page — they cannot create accounts on the fly.

24.3 End-user sign-in flow

What an employee sees:

1. They open https://platform.phishspot.com/users/sign_in.
2. Below the email/password form, separated by an “OR” divider, they see a Continue with Microsoft button (with the Microsoft logo). Clicking it redirects to the Microsoft sign-in screen.
3. Microsoft authenticates the user — including MFA if your tenant requires it. The user grants the PhishSpot app permission on first sign-in (a one-time consent per user, unless you’ve granted admin consent on their behalf, which suppresses the prompt entirely).
4. Microsoft redirects back to PhishSpot. Behind the scenes:
   • If a User row exists with the same email, it’s reused.
   • If not, a new User row is created with that email, marked confirmed.
   • PhishSpot caches the user’s Entra tenant ID for fast lookups.
   • Any unlinked Contact row matching the email is bridged to this user — they become “your contact, your user”.
5. The user lands on /guest/dashboard. No password was set. No invite email was sent. They’re in.

The first sign-in completes in one round-trip; subsequent sign-ins are even faster — Microsoft remembers consent, and the bridging step is a no-op after the first time.

24.4 The Guest Dashboard

/guest/dashboard is the employee-facing portal. It shows everything the employee is expected to engage with personally — and nothing else. They do not see other people’s results, the campaign list, account settings or any admin pages.

The dashboard has three sections:

24.4.1 Your training

The list of training assignments the employee has — typically one entry per phishing campaign that the employee clicked into and that has a course attached as the post-click outcome. Each row shows:

• The course name (e.g., “Świadomość phishingowa 101”).
• Completion status: not started / in progress (with % progress) / completed.
• A button to open the course player in the same tab.

Training assignments are derived from Deliverable records — when a contact reaches the clicked or later state on a campaign with a course, an obligation appears here.

24.4.2 Email history

The last 50 phishing simulation emails the user has interacted with. For each, the dashboard shows:

• The campaign name (the company-facing label, not the simulation-from address).
• Which actions the user took (opened / clicked / submitted form / reported).
• A timestamp.

This is the personal-history mirror of what admins see on the campaign dashboard. It’s deliberately short — long retention is an admin concern, not an end-user one.

24.4.3 Reported emails

If the user has reported phishing through the Outlook add-in (Chapter 20), each report appears here with subject, sender and the time it was reported. The section also displays the per-account reporting inbox address — useful for users on devices without the Outlook add-in installed, who can forward the suspicious mail manually instead.

24.5 The dual-role picker

Some users are both admins and employees: a security manager who runs phishing campaigns is also a phishing target themselves. PhishSpot handles this with an explicit picker.

When a user with both an account_user (admin role on at least one account) and a contact_membership (contact row on at least one account) signs in, the resolver routes them to /guest/role instead of straight to a dashboard. The picker shows two large card buttons:

• 🛡️ Admin panel — opens the account-scoped admin UI (/accounts/:account_id).
• 🎓 Training portal — opens /guest/dashboard.

The user picks once per session. The picker is also reachable from the user menu so admins can switch contexts mid-session.

A user with only an account_user (pure admin) skips the picker and lands directly on the admin dashboard. A user with only a contact_membership (pure employee) skips the picker and lands directly on /guest/dashboard. The picker only appears when both apply.

24.6 Security model

PhishSpot delegates authentication to Microsoft for SSO sessions. That means:

• MFA is enforced upstream. If your tenant requires MFA, every PhishSpot sign-in goes through it. If you don’t require MFA, PhishSpot does not silently re-impose it on the SSO path.
• Conditional access applies. Tenant policies (device compliance, geographic restrictions, app protection) gate the PhishSpot sign-in like any other Entra app.
• Tenant scoping (optional). PhishSpot can be configured to reject sign-in attempts whose Entra tenant ID doesn’t match any connected AccountOauthIntegration on the platform. This is recommended for tenants that don’t want any random Microsoft user to attempt sign-in.
• Local 2FA still available for non-SSO accounts. Admins who don’t sign in via Microsoft (e.g., service accounts) can still enable TOTP-based 2FA — see Chapter 15 User Profile & Preferences.

24.7 Troubleshooting

The Microsoft button takes me to “no access”. Either no Contact row matches your email on any account, or the tenant ID isn’t recognized. Ask your admin to confirm: (1) directory sync ran and your account was imported; (2) the integration is connected with admin consent (Chapter 25 §25.2).

I clicked Continue with Microsoft but Microsoft never asked me to consent. Admin consent is already granted in your tenant — that’s expected and faster.

I’m an admin and I keep landing on the role picker. That’s expected: you’re both an admin and a contact on the same account. Pick the role you want; the choice lasts for the current sign-in session.

I expected to see other employees’ results. You won’t — the Guest Dashboard only shows your own data. Aggregate dashboards are admin-only and live under the account admin UI.

24.8 Cross-references

• The directory sync that creates Contact rows from Entra: Chapter 25 Directory Sync.
• The Outlook add-in that feeds the “Reported emails” section: Chapter 20 Outlook Add-in.
• The campaign reports that admins use to monitor what employees see on this portal: Chapter 11 Reports & Analytics.
• Local TOTP-based 2FA for non-SSO accounts: Chapter 15 User Profile & Preferences.