Identity and access

Account for the identity and the permissions it receives

Employees, contractors, services, workloads and emergency administrators need identifiable owners and usable lifecycles. Record how credentials are issued, how permissions change and how access ends. Otherwise, the account or permission can remain after the work that justified it has ended.

NIST SP 800-63-4 addresses human identity assurance in relation to the transaction and user population. Strong authentication is useful, but it does not fix a server that lets an authenticated user read another tenant’s object. Check the identity decision and the authorization decision separately.

A former privilege survives in the session

In a fictional finance application, an employee changes roles and is removed from a directory group. An existing session still has cached permission to retrieve reports. The employee needs the application for other work, so disabling the entire account would also interrupt legitimate access.

Find where the application evaluates authorization, how the change reaches it and which sessions or tokens must be revoked. Browser sessions, API calls and export workers may use different mechanisms. Each needs to produce the access decision the organization actually intended.

Check the allowed cases as well as the denied ones

This matrix makes the intended behavior explicit before testing. It includes continued access and recovery because a system that simply denies every request would fail those requirements.

Follow access through its full lifecycle

Use an approved test to create access, change privilege, recover access and terminate it. Include refresh credentials, API keys, sessions, delegated grants and emergency credentials. They may retain authority independently, so measure how long the change takes rather than assuming the directory update was immediate everywhere.

Keep the identity, action, target and decision in the investigation record. Do not retain secrets or complete tokens. The administrator should have enough information to explain a rejection without asking the user for the credential itself.

An exception still needs revocation and recovery

A legacy integration may not support the preferred authentication mechanism. Give that exception a compensating control, owner and migration date, then test recovery and revocation along the exceptional path. An undocumented bypass can continue working long after the original dependency is gone.

Use the model to separate different access changes

The application and API guide includes an executable synthetic model for credential revocation, membership removal, role downgrade and expiry. It follows those changes through queued work and downloads. The effect is immediate at the next sequential decision in the model; that is not a measurement of latency in a deployed system.

For an actual workflow, identify the authority source, how long stale information may be used and whether a queued job acts for a user or for a service. Include legitimate access after the change. A role downgrade may remove writing while leaving reading available, and the implementation needs to preserve that distinction.

A workload token does not establish resource access

NIST SP 800-63-4 does not explicitly cover machine-to-machine authentication. For a workload, use the platform’s documented process for accepting an external identity and assigning a cloud principal. Then examine what that principal is permitted to do.

Federation can replace a long-lived cloud secret stored by an external job with token exchange. It still needs a specific trust configuration. Microsoft Entra compares issuer, subject and audience, including case. Google Cloud’s deployment-pipeline guidance uses mapped claims and attribute conditions to restrict which workloads using a shared issuer can gain access. Trusting the issuer alone does not identify the workload that should receive access, and the platform-specific settings are not interchangeable.

Suppose a fictional reporting job needs to read one billing-export bucket. Its trust configuration selects the repository and environment; its resource role allows the read. An owned job outside that selection should fail federation. The selected job should obtain its identity and read a fixture, but a write should fail. These are expected test results, not observations from a real environment. Obtaining the token checks only the first part.

Use the CSF identity and access questions to check the surrounding access lifecycle.

References: NIST Digital Identity Guidelines, Microsoft Entra: Workload identity federation concepts, Google Cloud: Configure Workload Identity Federation with deployment pipelines.