Identity Foundations: Start with the Right Core

Many organizations start with what they already bought (Google Workspace or Microsoft 365). That can work well. In other cases, complex app portfolios, multi-tenant requirements, higher assurance authentication, or mergers can justify adding a dedicated IdP (e.g., Okta).

The goal isn't "pick the fanciest IdP." The goal is an IdP you can operate cleanly: consistent MFA, clean admin model, lifecycle automation, and logs that support investigations. The platform choice matters less than the operating model around it.

• Good fits: the IdP you can enforce consistently across workforce apps, devices, and admin access.
• Not great fits: tools that require constant exceptions, or where key governance/logging features are locked behind plans you won't buy.

The decision usually comes down to three questions. First, does the IdP support the authentication methods you need (phishing-resistant MFA, device trust, SSO for your app portfolio)? Second, can you operate it with your current team, or does it require specialized expertise you'd have to hire for? Third, does the logging and audit trail meet your compliance and incident-response needs?

A common mistake is overinvesting in IdP selection while underinvesting in the operating model around it. The same IdP that works well with clear policies, defined admin roles, and lifecycle automation will fail badly when those pieces are missing. Start with the outcomes you need, then evaluate platforms against those requirements.

Identity doesn't exist in isolation. A strong identity core connects to several other controls that only work when the foundation underneath them is solid. Here's how the pieces fit together:

• MFA is the first layer on top of your IdP. It stops stolen passwords from becoming account takeovers. Without a working IdP and enrollment path, MFA rollout stalls at the first device swap.
• RBAC (Role-Based Access Control) determines who can do what. If your admin model is "everyone's a global admin," RBAC is academic. Clean identity foundations make least-privilege practical.
• Conditional Access adds context-aware rules (location, device posture, risk level) on top of MFA. These rules only work when your IdP reliably reports device state and sign-in signals.
• SSPR (Self-Service Password Reset) gives users a secure way to recover access without calling IT. It depends on MFA being enrolled and the IdP having verified recovery methods on file.

Each of these guides covers its own topic in depth. This page is the hub: the place to understand why the identity core matters before you start layering on controls.

MFA that resists modern phishing

• Baseline: require MFA for all users.
• Admins: require phishing-resistant methods where possible (FIDO2/WebAuthn, device-bound options, passkeys with the right controls).
• Reduce prompt fatigue: avoid "approve push" as the only method.

Admin model that won't explode later

• Separate admin accounts: don't admin from daily-driver accounts.
• Least privilege: delegate by task, minimize super/global admins.
• Break-glass: keep emergency access accounts protected and excluded from risky policies.

Device posture and access rules

• Define "managed": what qualifies (MDM enrollment, disk encryption, screen lock, OS version).
• Apply it where it matters: sensitive apps and data require stronger posture than low-risk apps.
• Don't overreach: locking down every app to managed-only devices creates friction and shadow IT if the policy doesn't match how people actually work. Focus on the sensitive apps first.

Lifecycle automation (joiners/movers/leavers)

• Provisioning: role/group-based access and automated app provisioning where possible (SCIM is common).
• Movers: when someone changes roles, their old access should be reviewed and reduced, not just added to.
• Offboarding: disable accounts, revoke sessions/tokens, transfer ownership, and remove SaaS access. See: Onboarding & Offboarding Playbook.

The goal is to make access changes repeatable and auditable, not dependent on someone remembering to update a spreadsheet. If your offboarding process starts with "email IT," you have a lifecycle gap.

Identity logs should answer: who signed in, from where, to what, and what changed. At minimum, ensure you can review:

• Admin actions (policy changes, role grants, MFA method changes)
• Sign-in events (success/failure, risk signals if available)
• OAuth/app consent events (new app access and tokens)

If you need longer retention or centralized investigations, route identity logs to your logging platform. Logs that no one reviews are the same as no logs at all.

A practical starting point: can you answer "who changed this admin role?" and "did this user sign in from an unexpected location?" within five minutes? If not, your logging needs attention before your identity program can be called operational.

• Vendor-neutral first: we design around outcomes and operating model, then map it to the right platform(s).
• Secure-by-default: policies are staged, tested, and monitored (not "flip the switch and hope").
• Built to scale: role-based access and lifecycle automation so growth doesn't break IT.
• Evidence-ready: we set up logging and access patterns so audits and security reviews don't become fire drills.