Authentication
Passkeys work as a first or second factor. Tenants choose password fallback, MFA by TOTP or passkey, and upstream SAML or OIDC federation. Saving an auth policy first shows a preview of readiness blockers and fallback paths that would break. Break-glass accounts are dedicated non-personal identities: each use needs a reason and is logged, and normal lockout rules apply.
Access requests and provisioning
Access requests go through request, approval, grant and execution, directly for Portal's own targets and through the connector catalog for other systems. Each execution starts from a provisioning plan that can't be changed. Completion, partial failure and retries are added as evidence. JML templates handle joiners, movers and leavers from HR events, manual kickoff or a scheduled effective date.
Access reviews
Access reviews enforce separation of duties in the backend, so nobody can certify their own access. The access graph shows every route to access (direct roles, groups, IGA grants and guest access) with provenance and trust level, giving "who has access and why" one answer, not four spreadsheets. Campaigns, decisions and revocations are recorded as evidence as they happen, as an ITGC access review control requires.
Moving from Okta or Entra
Migration has two modes: a clean cutover from Okta or Entra, or a merge into a running Portal estate. It snapshots applications, identity providers, routing rules, policies, groups and assignments, then sorts each item into one of five compatibility categories. A cutover plan applies only what it can prove will import. Okta TOTP factors carry over, so nobody re-enrolls.