Your Staff Have 24 Passwords. Your Business Has 24 Attack Surfaces.

Most companies don’t discover their identity problem until after the breach.

A departing employee’s account stays active in three systems because nobody updated the offboarding checklist. A contractor gets access to the finance portal because they needed "temporary" access six months ago and the ticket was never closed. A phishing attack succeeds not because your security was weak — but because your team was managing 24 separate login systems and nobody noticed one of them had no MFA.

This is the reality for most mid-size operations running between 15 and 30 internal systems. Not negligence. Just complexity that grew faster than the infrastructure to manage it.

---

The Problem Isn’t Your People

When staff reuse passwords across systems, it isn’t a discipline problem — it’s an ergonomics problem. When IT takes three days to fully offboard a resigned employee, it isn’t a process problem — it’s an architecture problem.

Every system that manages its own login is an island. Each island has its own passwords, its own session rules, its own access lists. And each island is invisible to the others.

The security risk compounds quietly:

• A warehouse supervisor leaves. HR disables their Microsoft 365 account. But their ERP login, their report portal, their warehouse management system — those run on separate credentials nobody thinks to revoke.
• A finance manager’s laptop is stolen. IT resets their email password immediately. But the accounts receivable portal uses a different password stored in a sticky note on the desk.
• An audit requires access logs showing who accessed financial data in Q3. Each system has its own logs. Some have none at all.

None of these are hypothetical. They are the standard failure modes of fragmented identity infrastructure.

---

What Single Sign-On Actually Solves

Single Sign-On (SSO) is not a login convenience feature. It is an identity control layer — the architectural decision to make one system responsible for answering the question: who is this person, and what are they allowed to do?

When every application delegates that question to a single Identity Provider, several things become structurally impossible:

Ghost accounts disappear. When an employee is deactivated in Azure AD, every connected system loses access simultaneously. Not after a checklist. Not after three days. Immediately and automatically.

Audit trails become coherent. Every login, every session, every access attempt flows through one system. One log. One query. A complete picture.

MFA becomes universal. Instead of hoping each application has MFA configured correctly, you enforce it once at the identity layer. Every application inherits it.

Credential theft becomes less catastrophic. A phished password is dangerous when it unlocks multiple systems. With SSO, your staff don’t have multiple passwords to steal — and the single authentication point can enforce step-up verification for sensitive systems regardless.

---

How It Works in Practice

The architecture is straightforward. An Identity Provider — in this case Authentik, federated to Microsoft 365 — sits in front of all your internal systems. Every application points to it for login. Authentik points to Azure AD to verify the user’s identity.

flowchart TD
    subgraph STAFF["👤 Staff"]
        B[...]
    end

    subgraph PORTAL["🌐 App Portal"]
        AP[...]
    end

    subgraph AUTHENTIK["🔐 Authentik — Identity Provider"]
        AK[One login gateway\nfor all systems]
    end

    subgraph AZURE["☁️ Microsoft 365 / Azure AD"]
        AAD[Source of truth\nfor all identities]
    end

    subgraph APPS["Your 24 Systems"]
        direction LR
        T1["🖥️ ERP · Finance · Warehouse\nDocument Control · HR Portal"]
        T2["📱 Email · Phone · Messaging"]
        T3["🖨️ Printers · Hardware"]
    end

    B -->|"One login"| AP
    AP -->|"Who is this user?"| AUTHENTIK
    AUTHENTIK -->|"Verify identity"| AZURE
    AZURE -->|"Confirmed"| AUTHENTIK
    AUTHENTIK -->|"Access granted + roles"| APPS

    style AUTHENTIK fill:#EBF3FB,stroke:#2E75B6,stroke-width:2px
    style AZURE fill:#E8F4E8,stroke:#375623,stroke-width:2px
    style STAFF fill:#FFF9E6,stroke:#7F6000,stroke-width:2px
    style PORTAL fill:#FFF9E6,stroke:#7F6000,stroke-width:1px
    style APPS fill:#F5F5F5,stroke:#999999,stroke-width:1px

Staff see none of this. They open the portal, click the app they need, and they’re in. If they’ve already logged into their Microsoft account that morning, they don’t see a login screen at all.

What happens on first login:

sequenceDiagram
    actor Staff
    participant Portal as App Portal
    participant Authentik as Authentik
    participant Azure as Azure AD
    participant App as Any of your 24 apps

    Staff->>Portal: Open browser
    Portal->>Authentik: No session found
    Authentik->>Azure: Redirect to MS365 login
    Azure-->>Staff: Enter email + password
    Staff->>Azure: Authenticate (+ MFA)
    Azure-->>Authentik: Identity confirmed
    Note over Authentik: Check groups, apply roles,<br/>enforce MFA policies
    Authentik-->>Staff: Session established ✓
    Portal-->>Staff: Show personalized app tiles

    Staff->>App: Click any tile
    Note over Authentik: Session already exists — skip login
    Authentik->>App: Issue access token with roles
    App-->>Staff: Access granted ✓

Every login after that:

sequenceDiagram
    actor Staff
    participant App as Any of your 24 apps
    participant Authentik as Authentik

    Staff->>App: Open app directly
    App->>Authentik: Validate session
    Note over Authentik: Session valid — no login needed
    Authentik->>App: Access token issued
    App-->>Staff: Access granted ✓ — zero prompts

Behind the scenes, the Identity Provider is doing substantial work on every request: verifying the session, checking group memberships, enforcing MFA policies, injecting role-specific claims into the access token, and writing to a unified audit log.

For your applications, integration is lightweight. Each system receives a client ID and a client secret. It discovers all authentication endpoints automatically from a single configuration URL. When a user arrives, the application asks the Identity Provider to vouch for them. The Identity Provider responds with a signed token containing everything the application needs — identity, groups, roles, access level. The application grants access and moves on.

The custom work is minimal: mapping your existing Azure AD groups to application-specific roles, configuring step-up MFA for sensitive systems, and building the portal tile launcher that shows each user only the applications they’re authorized to access.

---

The Offboarding Problem, Solved

The most underestimated benefit of SSO is what happens when someone leaves.

In a fragmented system, offboarding is a checklist. Someone — usually IT, sometimes HR, occasionally nobody — works through a list of systems and manually revokes access. Systems get missed. The checklist isn’t updated when new applications are added. The person who maintained the list left six months ago.

With SSO and SCIM provisioning, offboarding is an event, not a process. The moment an account is deactivated in Azure AD, a SCIM push propagates that change to the Identity Provider. Active sessions are invalidated. Every connected application stops accepting that identity. All 24 systems, simultaneously, without a checklist.

sequenceDiagram
    participant HR as HR / Manager
    participant Azure as Azure AD
    participant Authentik as Authentik
    participant Apps as All 24 Systems

    HR->>Azure: Deactivate employee account
    Azure->>Authentik: SCIM push — account deactivated
    Note over Authentik: Invalidate all active sessions
    Authentik-->>Apps: Access revoked across all 24 systems
    Note over Apps: Simultaneous. No checklist.<br/>No gaps. No forgotten systems.
    HR-->>HR: Done ✓

Compare that to the alternative: a manual checklist, worked through system by system, by someone who may not know which systems the employee had access to, on a list that hasn’t been updated since the last IT handover.

For a company with high staff turnover — common in food manufacturing and distribution — this is not a small thing. Every day a deactivated account remains accessible in a production system is a liability.

---

What to Expect From Implementation

A well-scoped SSO implementation for 24 systems runs approximately 10 weeks end-to-end. The phases are predictable:

The first two weeks establish the foundation: installing the Identity Provider, connecting it to your Microsoft 365 tenant, and verifying that federation works correctly. No applications are migrated yet — this phase is entirely infrastructure.

Weeks three and four connect all 24 applications. Each application is registered with a client ID, redirect URI, and access policy. Group-based authorization is configured. The configuration is exported as version-controlled YAML blueprints — reproducible and auditable.

Week five handles the custom work: ERP role mapping for systems like Infor M3 that need application-specific attributes in the access token, and step-up MFA policies for sensitive systems.

Week six delivers the user-facing layer: the application portal, Thai language localization, company branding on all authentication screens.

Weeks seven and eight connect the communication tools — phone systems, messaging platforms — through account linking stages that tie each staff member’s application account to their Azure AD identity.

The final two weeks are testing, user acceptance, and handover: a complete test plan per application, a facilitated UAT session with your IT team, and a full documentation package covering architecture, administration procedures, and emergency access protocols.

---

The Question Worth Asking

The question isn’t whether your organization needs centralized identity management. If you’re running more than ten internal systems, you already need it.

The question is whether you discover that need before or after something goes wrong.

A legacy ERP with no MFA, a departed employee’s credentials still active in a warehouse system, an audit request you can’t fulfill because the logs are fragmented across twelve applications — these are not edge cases. They are the predictable outcomes of identity infrastructure that scaled without architecture.

SSO doesn’t eliminate all security risk. But it eliminates the specific category of risk that comes from fragmentation: the ghost accounts, the silent credential reuse, the offboarding gaps, the audit black holes.

For operations running on Microsoft 365, the foundation is already there. Azure AD is the identity authority you’re already paying for. The work is connecting your other 23 systems to it — and making sure the connection is robust, auditable, and centrally controlled.

---

Interested in connecting your existing systems to a centralized SSO layer? We work with organizations running Microsoft 365 to implement Authentik-based identity infrastructure — covering OIDC, SAML2, LDAP, and custom integrations for ERP and communication tools. Get in touch to discuss your environment.