Authentication is the door. Every other security control in a platform — permissions, audit trails, data access policies — sits behind it and assumes it's working. Get authentication right and the rest of the security story has a foundation; get it wrong and either the door is too porous (and the perimeter is an illusion) or it's too strict (and legitimate users spend their days fighting the system that's supposed to serve them). The platform ships with the full lifecycle set that real organizations actually need — self-service reset, password rotation rules, block and unblock, forced logout, auditable impersonation — so admins aren't left building those controls around the outside.
Email and password login is the default path. A user enters their email and password; the platform validates; the session starts. Password complexity rules are configurable per tenant — minimum length, character class requirements, disallowed patterns — so organizations with formal policies can enforce them and organizations without can pick sensible defaults. Password storage uses modern key-derivation schemes; the specifics stay where they belong, out of the application surface.
Self-service password reset is the email-driven recovery path every user eventually needs. The user requests a reset, the platform emails a time-limited token, the user follows the link, sets a new password, and is signed back in. Tokens expire on a sensible schedule so that a stale reset email can't be used to hijack an account weeks later. The flow includes redirect-URL handling — if the user was trying to reach a specific page when they needed to reset, the platform remembers the destination and returns them there after the reset completes. That's the small thoughtfulness that keeps a password reset from also being a navigation disruption.
Password expiry enforces rotation on a schedule, per tenant. Organizations that operate under policies requiring, say, a password change every ninety days can configure exactly that, and users are prompted to rotate when the window elapses. Organizations that don't need rotation can leave it disabled. The choice belongs to the tenant rather than being baked into the platform, because the right rotation cadence depends on the threat model and the regulatory environment.
Blocking and unblocking is the lifecycle control for accounts that shouldn't currently have access but also shouldn't be permanently removed. A user on leave, a user under investigation, a user whose access is paused pending a policy review — all of these cases fit "blocked." The account still exists, its data relationships are preserved, the audit trail of what it did in the past is intact; it just can't sign in until unblocked. That's usually the right shape for a temporary suspension, and it's much cleaner than deleting and recreating the account.
Account termination and reinstatement handle the more final cases where a user has left the organization. A terminated account can't sign in, but its presence in records — who created this, who last edited that — remains so history stays coherent. If a terminated user rejoins later, reinstatement restores access without a fresh onboarding. The terminated state is distinct from the blocked state because the expectations around each are different, and keeping them separate gives admins the right vocabulary for the situation they're actually in.
Account validity windows are the scheduled variant. An account can be configured with a validity range — valid from this date, valid until that date — and the platform enforces the window automatically. That's useful for contractor accounts with defined engagement periods, seasonal staff, interns with a known end date, or any scenario where access should end at a specific time without relying on someone remembering to block the account manually. The scheduler handles the transitions so that "access ends on the last day of the engagement" actually means that.
Forced logout is the admin action that ends all active sessions for a specific user immediately. A laptop was lost; a device was compromised; a password rotation policy wants to invalidate old sessions. Whatever the reason, the admin can force the user's sessions to end without touching the account state in any other way. The user re-authenticates on their next attempt; any active tokens or cached credentials are no longer valid. For the incidents where "cut access right now" is the correct answer, this action is the one-click path.
Cancel pending password change is the counterpart to the reset flow. If a user mistakenly requests a reset, or if an admin suspects a phishing-initiated reset, the pending change can be revoked before the user completes it. The existing password remains valid; the token is invalidated; any subsequent attempt to use the reset link fails. This matters in adversarial scenarios where an attacker initiates a reset hoping to intercept the email: admins have a way to shut it down without forcing the user to change anything.
Impersonation with audit is the support feature that keeps helping users from becoming a security hole. Authorized staff can sign in as a specific user to see what they see — essential for diagnosing "it doesn't work for me" reports where the issue is role-specific or data-specific — and every second of every impersonated session is logged. The event log records who impersonated whom, when, and what happened during the session. That combination is what makes impersonation genuinely useful: support agents can do their job efficiently, and the organization has a complete record for compliance or forensic purposes. The alternative — asking users for their passwords, or screen-sharing through their eyes — is both less effective and less auditable.
What comes next depends on the tenant's identity strategy. Single sign-on integrates the platform with an identity provider for organizations that centralize authentication; the SSO article covers that path. Magic-link login replaces passwords with email-based one-time access for contexts where passwords are more friction than they're worth; the magic-link article covers that. User invitations handle the onboarding flow for new users; the invitations article covers the shape of that. The event log article covers the audit trail that records all of these authentication events for compliance. Authentication is the door; the other articles cover the surrounding infrastructure that keeps the door well-maintained.