Why identity is still the weakest link

What makes identity a security boundary?#

Identity security controls who can obtain authority, what that authority permits, and how long a system continues to recognize it. Authentication establishes a claim about an account or authenticator. Authorization decides whether a particular action on a particular resource is permitted. Session management carries authority between requests. Enrollment, account recovery and departure change who can exercise that authority. A failure in any part can undermine the others.

The phrase weakest link is a review hypothesis, not a universal ranking of incident causes. An application with excellent sign-in controls may still allow a legitimate user to access the wrong tenant, preserve an administrator session after demotion, or let a support procedure replace an authenticator without sufficient checks. Begin by describing these transitions, rather than assuming a login setting answers the whole question.

OWASP distinguishes authentication from authorization and recommends permission validation for every request. The practical implication is to follow one consequential operation across the full path: account identity, current permission, resource ownership, session state, resulting mutation and recorded outcome. Each step needs an explicit decision and an owner.

How should permissions reflect the work?#

A useful permission describes an action, a resource and the conditions under which access is allowed. Read an assigned support case is more precise than support access. Approve a refund below an agreed threshold is more precise than billing administrator. Roles can group these permissions, but a role name cannot establish tenant ownership, current assignment or whether a second person must approve the operation.

Build a small access matrix around real workflows. Include employees, customers, service accounts, temporary contractors and emergency operators. For each workflow, identify the smallest scope that lets the person finish their work and the event that should remove it. Record who approves exceptions and when they expire. A role that everyone receives because nobody can explain it deserves investigation.

Enforcement belongs where a protected read or mutation becomes possible. A disabled control in the interface helps users understand their options; a direct API call still needs its own permission decision. Review list endpoints, object endpoints, downloads, background jobs and exports together. A consistent boundary includes legitimate denial behavior, so a denied update must leave the record unchanged and reveal no protected details.

Which authentication properties matter?#

Choose authentication controls by the access they protect and the threats they must withstand. NIST SP 800-63B-4 distinguishes phishing-resistant cryptographic authentication from methods that require manually entering an output such as a one-time code. A generic MFA enabled status conceals that distinction. A method also has operational properties: who can enroll it, where it can be used, how it is recovered and how its loss is handled.

For privileged workflows, examine the weakest permitted route into the same account. A strong normal sign-in may coexist with a weaker recovery method or a retained legacy integration. Inventory those routes before changing the primary authenticator. A migration plan should specify compatible clients, accessible enrollment, support escalation and removal of obsolete routes.

Authentication assurance does not directly answer application authorization. Even a correctly authenticated administrator should encounter resource and action constraints. Likewise, a compromised endpoint can expose an active session after a sound authentication event. Treat authenticators as one important boundary within the system, with verification appropriate to their documented properties.

How does authority continue after sign-in?#

A session is continuing authority recognized by the application after authentication. Review how it is issued, stored, refreshed, expired and invalidated. Cookie transport and access attributes can reduce particular exposure paths, but a header review cannot show whether the server stops accepting a session after departure. The authoritative question is whether a subsequent protected request is accepted under the current policy.

OWASP recommends renewing session identifiers after privilege changes, enforcing expiration on the server and invalidating sessions during logout. Implementation details vary between opaque sessions, access tokens and refresh tokens. A self-contained token can remain usable until expiry unless the receiving service also consults revocation or current account state. Define the acceptable revocation delay before choosing a mechanism.

Ask separately about account disablement, password change, authenticator removal, tenant removal, device loss and role reduction. These events need not share the same handling, but the differences should be deliberate. Consider requests already in flight and queued work. Revoking a browser session does not necessarily cancel a job submitted earlier; the worker needs a rule for whether authority is checked at execution time.

Show operators the distinction between local logout, identity-provider logout and application-session invalidation. Record non-secret identifiers and timestamps that connect the event to the denial decision. The system should explain what was terminated and which classes of authority remain pending.

How should enrollment, recovery and departure be reviewed?#

Enrollment grants a new means of claiming an identity. Recovery replaces access when the usual means is unavailable. Departure removes access that was previously legitimate. Review these as changes to authority, with evidence requirements appropriate to the consequences. A support agent should understand what they are allowed to restore and what requires escalation.

Model recovery as a sequence rather than an email template: receive a request, establish the account, evaluate evidence, authorize the change, notify relevant parties and verify resulting access. Identify what a malicious claimant could know without being the account owner. Public profile information, a familiar writing style or possession of an old ticket should not silently become sufficient proof.

Departure needs an inventory beyond the employee directory. Include application sessions, cloud access, API credentials, shared operational accounts, recovery addresses and ownership of scheduled work. Transfer essential ownership without transferring secret material casually. Where immediate removal is required, test the actual downstream effect; a completed directory task is only evidence about the directory.

Which control addresses which identity failure?#

Select a control by the failure it constrains. The comparison below is a design aid, not an assurance ranking. Combine controls when authority crosses more than one boundary, and assign an observable acceptance condition to each choice.

Fictional worked example: removing support export authority#

This fictional example illustrates a review method; it is not a client result. A multi-tenant case-management product permits support staff to read assigned cases. A temporary export permission allows a specialist to produce a tenant-scoped diagnostic bundle. The intended rule is that removing this permission prevents new exports immediately, while already approved bundles remain accessible only through their existing expiry and tenant rules.

The review starts with two synthetic tenants and three controlled accounts: an assigned support specialist, an unassigned colleague and a tenant administrator. The team creates harmless records with distinct markers. It tests allowed reads and exports, denied access to the other tenant, and permission removal while the specialist retains an active browser session. An export request is denied in the user interface, but a queued request submitted before removal still executes afterward.

The observed result establishes a timing gap in this workflow. It does not establish that every export is exposed or that a real customer record was accessed. Engineering finds that the queue stores a submitter identifier and tenant identifier, while the worker relies on the authorization result from submission. The agreed change requires a current permission check when execution begins and binds output access to the tenant and requester.

The acceptance criteria specify that revoked authority cannot start an unexecuted export, legitimate exports still work, denied jobs produce no bundle, and operators can distinguish cancellation from failure. The retest repeats the original scenario and adds removal between queue receipt and worker execution. It records build identity, permission-change time and job decision time. Those observations let the team assess the intended immediate boundary without claiming an unmeasured fleet-wide revocation guarantee.

The remaining decision is operational: whether a job already performing work should stop or complete under a recorded approval. The product owner chooses the rule explicitly, and engineering adds that case to the runbook rather than letting timing decide it.

What evidence should an identity review collect?#

Use controlled accounts and harmless fixtures in an authorized environment. Compare expected and observed behavior, including the resulting data state. Preserve enough non-secret evidence to reproduce the decision without collecting reusable credentials.

• Identify the principal, tenant, resource, permitted action and reason for access in each test.
• Exercise a legitimate request and a closely related denied request through the authoritative endpoint.
• Remove a permission while a controlled session remains active, then record the next protected request's result.
• Test account disablement, authenticator replacement and recovery using the documented operating procedure.
• Verify exports, downloads and queued work rather than stopping at the visible application screen.
• Check that denial creates no mutation and does not disclose another tenant's protected information.
• Record build or configuration identity, relevant timestamps, decision evidence and unresolved limitations.
• Give each failed expectation an owner, acceptance condition and scoped retest.

What should a team do next?#

Choose one consequential workflow and produce its authority map: entry methods, permission decision, continuing session, downstream jobs and removal events. Resolve unclear rules with the business owner before implementing controls. An engineer cannot test immediate revocation if nobody has decided whether immediate means before the next request, before execution of a queued job, or after a documented token lifetime.

Prioritize the gaps that combine meaningful authority with an unclear lifecycle. A read-only internal view and a cross-tenant export require different urgency and evidence. Make narrow changes with observable effects, then retest the intended boundary and legitimate workflow together.

Every additional central check adds availability and latency considerations. Caching improves responsiveness but introduces staleness; short lifetimes reduce exposure but can interrupt legitimate work; restrictive recovery can exclude the real user if support cannot resolve exceptions. Record these tradeoffs and the chosen failure behavior. A scoped identity review provides evidence about the paths tested, not proof that every identity risk is removed.