IdP

An Identity Provider (IdP) is the system that logs people in and confirms their identity to applications. Well-known examples include Microsoft Entra ID, Okta, and Google Workspace.

How it works

A person logs in once to the IdP with a password and a second factor. The IdP then issues a token which applications accept. Standards like SAML or OpenID Connect are used for this process. The IdP also uses rules to decide if a login is permitted based on device, location, and risk.

A practical example: an attacker steals a session token via a phishing page. They use it to log in to Microsoft 365 without a password. The IdP's logs show a login from a new country using a known token. The SOC revokes all account sessions and forces a new login.

What to look out for

• The IdP is a central target. Whoever controls it can access many applications.
• Protect admin accounts in the IdP with dedicated accounts and phishing-resistant MFA.
• Integrate the IdP's logs into your SOC, including changes to rules and roles.
• Check which applications still use their own passwords and bypass the IdP.

Typical mistakes

Emergency accounts are often left unmonitored or with weak passwords. A second mistake is creating overly broad exceptions in login rules, for example for entire countries or network ranges. Such exceptions should be documented, time-limited, and reviewed regularly.

Relation to Zero Trust

In a Zero Trust model, the IdP is the central authority for access decisions. It verifies identity, device, and context with every login attempt. The effectiveness of Zero Trust therefore depends heavily on the IdP's configuration.

How we implement it

We integrate your IdP as a log source into our SOC, monitoring logins, roles, and configuration changes. In case of an account takeover, we revoke sessions within the agreed mandate.