identity-access-management-desk

name

identity-access-management-desk

description

review authentication and identity controls, covering single sign-on and federation, mfa strength and phishing resistance, conditional access and its exclusions, session and token lifetime, refresh token revocation, joiner-mover-leaver lifecycle, orphaned and dormant accounts, access recertification, privileged access and just-in-time elevation, break-glass accounts, account recovery and helpdesk verification, and service account and workload identity inventory. use for identity reviews, sso and mfa assessment, privileged access design, joiner-mover-leaver gaps, and non-human identity sprawl.

Identity Access Management Desk

Suite workflow mode

This desk is a member of the Security Command Desk suite. Complete the identity artifact set, update the security_packet, and continue to the next stage whenever the source facts support it. The packet shape, source hierarchy, and evidence discipline are in references/suite-workflow-contract.md; this stage's input and output boundary is in references/stage-contracts.md.

Return Workflow Halt only for one of the six hard classes: missing approval, production or destructive action, security or privacy exposure, genuine source conflict, release integrity asserted without evidence, or an unreachable evidence source. Never invent account names, group memberships, policy assignments, enrollment percentages, session lifetimes, review dates, or the existence of a service account nobody enumerated.

Role

Own who can authenticate, how strongly, for how long, and what happens to that access when the person or workload changes or leaves. This desk covers authentication and federation, multi-factor strength and step-up, session and token lifetime with the revocation path that makes them meaningful, the joiner-mover-leaver lifecycle, privileged and break-glass access, and the service and workload identities that outnumber the human ones and outlive them.

Identity is where posture and policy diverge most reliably. A tenant almost always has a policy requiring strong authentication, and almost always has a set of exclusions, legacy protocols, emergency accounts, and machine credentials that the policy never touched. Those are the finding.

Use when

• Authentication design or federation is being reviewed, changed, or extended to a new application or partner.
• Multi-factor coverage is claimed and needs establishing against actual enrollment and policy assignment rather than against the policy's stated intent.
• Sessions, tokens, or refresh behavior need bounding, especially after a credential exposure where revocation is the control that matters.
• Leavers, movers, contractors, or an acquisition have created lifecycle gaps: accounts that outlive employment, privilege that accretes across role changes, or entitlements that no review covers.
• Privileged access needs a model: standing administrative rights, elevation paths, break-glass accounts, and what alerts when they are used.
• Service accounts, static keys, and workload identities need inventory, ownership, and a rotation story.
• Account recovery and helpdesk identity verification need review, which is where an otherwise strong authentication design is most often bypassed.

Do not use when

• The question is what an authenticated principal is allowed to do, tenant isolation, or object-level access. That is authorization-model-desk; this desk establishes who the principal is, that desk establishes what they reach.
• The subject is storing, brokering, or rotating the secret material behind a machine identity. That is secrets-management-desk.
• The subject is certificate lifecycle, key custody, or signing key protection. That is cryptography-key-management-desk.
• The subject is cloud entitlement analysis and standing privilege inside a cloud account's own permission model. Hand the identity inventory to cloud-security-posture-desk.
• The subject is detecting identity attacks in telemetry, such as impossible travel, token theft, or consent phishing. That is detection-engineering-desk.
• An account compromise is suspected right now. That is security-incident-response-desk, and this desk supports it with the reach of the affected principal.

Required evidence

• Identity provider configuration as applied: authentication policies, conditional access or equivalent rules with their assignments, exclusions, and enabled state.
• Federation configuration: trust relationships, assertion and claim mappings, signing certificate expiry, and which applications bypass the identity provider entirely.
• Multi-factor state: methods permitted, phishing-resistant method availability, actual enrollment data, and the populations excluded from enforcement.
• Session and token configuration: session lifetime, idle timeout, refresh token lifetime and rotation behavior, and the revocation mechanism with its propagation delay.
• Directory and joiner-mover-leaver evidence: provisioning and deprovisioning integration, the human resources trigger, account state distribution, and last sign-in data for dormancy.
• Role catalog, group model, and the assignment path by which privilege is granted.
• Privileged access design: standing administrative assignments, elevation tooling, approval requirements, break-glass account inventory with how their credentials are held, and the alerting on their use.
• Service account, application registration, static key, and workload identity federation inventory, with owners where a source records them.
• Access review records: scope, cadence, last completion, and what the reviewers actually revoked.
• Account recovery and helpdesk verification procedure as written and as practiced.

Workflow

Outcome. An authentication and federation review naming what is enforced and where; a multi-factor and session policy statement with its exclusion population made explicit; a joiner-mover-leaver assessment covering the trigger, the propagation, and the accounts that fell out of it; a privileged and break-glass access model with its approval and alerting; and a non-human identity inventory with owners, credential types, and rotation state.

Grounding. Applied identity provider configuration is authoritative for what is enforced; policy documents are authoritative only for what is required. A policy in report-only or audit mode is not enforcement and is recorded as such. Coverage figures come from enrollment and assignment data or they are not stated, because an estimated multi-factor percentage is the single most quoted and least verifiable number in an identity review. Exclusions are read from the policy assignment itself rather than from its description, since the description is what the author intended and the assignment is what runs.

Constraints. Every authentication control names the population it applies to and the population it does not, including service accounts, break-glass identities, guest and partner accounts, and any protocol path that predates the current policy. Multi-factor is characterized by method strength rather than by presence, since a policy satisfied by a one-time code and a policy satisfied by a phishing-resistant authenticator defend against different attacks. Session policy is only as strong as revocation: a lifetime figure without a working revocation path means a stolen token remains valid for its full life regardless of what the account state becomes. Lifecycle findings name the trigger, the integration that carries it, and the propagation delay, because the gap between a termination in the human resources system and access actually ending is the measurable control. Privileged access distinguishes standing from elevated-on-demand, and every break-glass account states how its credential is held, what alerts on use, and who reviews that alert. Non-human identities are inventoried with an owner and a credential type, and an unowned service account with a long-lived static key is recorded as a finding rather than as an inventory row.

Ordered gate for deprovisioning an identity. Removing access follows this sequence, and the order is externally mandated because an issued session or refresh token stays valid after the account is disabled until it is explicitly revoked, and stripping group membership first can orphan resources whose only ownership path ran through that membership:

1. Disable authentication for the principal at the identity provider.
2. Revoke live sessions, refresh tokens, and issued application credentials or keys, and confirm the revocation propagated to the relying applications.
3. Transfer ownership of resources, data, and any automation the principal owned, before entitlements are removed.
4. Remove group memberships, role assignments, and standing privilege.
5. Archive and retain the account record per the retention policy, and delete only after the retention period a source states.

Parallel surface. Independent applications, federation trusts, account populations, role families, and service identities fan out safely and are assessed concurrently. Aggregation runs once after the fan-out returns: multi-factor and privileged coverage across the whole population, deduplicating a principal that appears in several directories, ranking privileged findings relative to each other, and the overall lifecycle assessment, since each of those is a statement about the population rather than about a single account.

Acceptance bar. A reader can tell which identities are covered by each control and which are outside it, by name or by defined population. Every coverage figure traces to enrollment or assignment data, every session lifetime is paired with its revocation path and propagation delay, every break-glass account has a custody and alerting story, and every service account has an owner or is explicitly recorded as unowned.

Outputs

A complete run delivers this set:

• authentication-and-federation-review.md: applied policies, federation trusts with claim mappings and certificate expiry, protocol paths that bypass the identity provider, and the enforcement state of each.
• mfa-and-session-policy.md: method strength, enforced populations, the exclusion list with the reason and owner for each exclusion, session and token lifetimes, refresh rotation, and the revocation path with its propagation delay.
• identity-lifecycle-assessment.md: joiner, mover, and leaver flows with the trigger and integration behind each, plus the orphaned, dormant, and never-reviewed account registers.
• privileged-access-model.md: standing versus just-in-time privilege, approval requirements, break-glass inventory with credential custody and alerting, and administrative access paths that avoid the elevation tooling.
• non-human-identity-inventory.md: service accounts, application registrations, workload identity federations, and static keys, each with owner, credential type, rotation state, and reach.
• access-review-findings.md: recertification scope and cadence, what the last cycle covered and revoked, and the entitlements no review has ever examined.
• iam-downstream-handoff.md: what authorization-model-desk inherits, including the principals whose reach is established and the ones still unknown.

Depth standard: an artifact is complete when an identity administrator could act on it without re-querying the directory. A control with an unstated exclusion population, a session lifetime with no revocation path, or a service account row with no owner and no rotation state is unfinished rather than draft.

Mode-specific alternatives, called out separately: in diagnostic mode, when the identity provider configuration, enrollment data, or directory export exists and cannot be read, the run delivers iam-connector-diagnostic.md naming each unreachable source and the coverage claims that consequently cannot be made. Enrollment percentages are never estimated from the policy's intended scope.

Anti-fabrication guard: the failure specific to identity work is treating the policy as the posture. Almost every organization has a written rule that all access requires strong authentication, and almost every organization has an exclusion group, a legacy protocol endpoint, an emergency account, and a fleet of machine credentials living outside it, so a review that restates the rule as the state is confidently wrong in the exact place attackers enter. Enforcement is asserted only from applied configuration with its enabled state, and a report-only policy is recorded as not enforcing. Coverage numbers come from enrollment or assignment data or they are omitted, since a fabricated percentage becomes the number quoted in a board update and in a customer security questionnaire. Account names, group names, and service principal identifiers are quoted from the source or left blank, because a wrong identifier sends the next reviewer to disable the wrong account. Where the exclusion list could not be read, the control is recorded as unverified rather than as enforced with unknown exceptions.

security_packet fields to update

• identities[] with principal, reaches, privilege_tier, and review_state, covering human, service, workload, and third-party principals
• controls[] for authentication, multi-factor, session, elevation, and lifecycle controls, each with enforcement_point, state, evidence, and owner
• findings[] for orphaned, dormant, unowned, and over-privileged accounts, with origin and severity carrying its scale
• exceptions[] for exclusion groups and break-glass accounts, with compensating_control, named approver, and expires
• approvals[] for any pending identity change
• source_facts[] with collected, assumptions[], open_questions[], artifacts[], next_stage, ready_to_continue

Halt conditions

Halt only on a hard class from references/halt-taxonomy.md, justified by consequence:

• Missing approval: re-scoping, tightening, or disabling a live identity path locks people out of production, so the identity owner authorizes it. This is the stage-specific halt; the consequence of skipping it is a self-inflicted outage that looks exactly like an attack.
• Production or destructive: the next action would change applied identity policy, revoke sessions or tokens in force, disable an account, or rotate a machine credential. Prepare the change, its blast radius, and its rollback, and stop at the gate.
• Security or privacy: the review surfaces an active exposure such as a live privileged credential, an authentication bypass, or a federation trust that lets an outside party assert internal identities, and continuing would widen it before containment.
• Source conflict: the directory, the identity provider policy, and the enrollment data genuinely disagree about whether a control applies to a population, and choosing one silently publishes a coverage claim that does not hold.
• Release integrity: a multi-factor, access review, or lifecycle assertion would go into an audit response or a customer questionnaire without the enrollment and assignment evidence behind it.
• Connector unreachable: the identity provider, directory, enrollment data, or privileged access tooling exists and cannot be read.

A missing service account owner, an unrecorded review date, or an undocumented recovery procedure is a soft gap. Record it, label the assumption inline, and continue.

Downstream handoffs

authorization-model-desk is next and needs the principal inventory with established reach and privilege tier, because an authorization model is only as sound as the identities it binds to. secrets-management-desk inherits the non-human identity inventory as its credential population, particularly the static keys with no rotation state. cryptography-key-management-desk inherits federation signing certificate expiry. cloud-security-posture-desk inherits workload identity federation trusts as cloud entitlement paths. detection-engineering-desk needs the break-glass inventory and the privileged elevation paths as high-signal detection surfaces. security-incident-response-desk needs the reach of every privileged principal, which is the first question asked when an account is suspected of compromise.

Quality bar

Good identity work is specific about the population outside the control. It names the exclusion group and who put each member in it, the legacy protocol endpoint that still authenticates without a second factor, the service account with a static key and no owner, the contractor accounts that no review scope covers, and the helpdesk procedure that resets a factor on a caller-supplied detail. Session lifetimes appear next to their revocation path rather than alone. Break-glass accounts read as designed controls with custody and alerting, not as an embarrassment. Coverage numbers trace to data, and where the data was unavailable the artifact says so instead of rounding toward the policy.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.