Entra Enterprise apps and App registrations - Global Secure Access - Conditional Access Block

This behavior makes sense once you separate user authentication from application authentication.

There are two different OAuth models involved.

Delegated authentication is when a user signs in interactively and the application receives a token on behalf of that user.

Application authentication, also known as client credentials flow, is when the application authenticates as itself using a client ID and a client secret or certificate.

If the third party applications are using client secret authentication, they are not authenticating as the administrator who granted consent. The administrator only granted permissions once. After that, the application uses its own identity, represented by a service principal in Entra ID, to request tokens.

Because there is no interactive user sign in during client credential flow, password changes and MFA do not affect it. However, Conditional Access policies can block token issuance depending on how they are scoped.

If your Conditional Access policy is set to block access to all cloud apps, and it applies to workload identities or service principals, it can prevent those applications from obtaining tokens even though no user is signing in.

Regarding best practices for third party application authorization:

Using a dedicated account to grant admin consent is good governance, but it does not change how authentication works afterward. The application should authenticate using its own service principal, ideally with certificate credentials instead of long lived client secrets. Permissions should follow least privilege principles and service principal sign ins should be monitored regularly.

For applications used directly by regular users, most of them rely on delegated authentication. In that case the user signs in, Conditional Access is evaluated, and tokens are issued in the user context. These applications do not use a client secret tied to the user account. They use interactive OAuth flows.

Architecturally, the key distinction is this:

Client credential flow is evaluated as workload identity authentication.

Delegated flow is evaluated as user authentication.

If your Global Secure Access rollout includes a broad block policy, review whether workload identities are included in scope. Testing in report only mode first is strongly recommended to identify dependencies before enforcing.

A useful validation step is to review sign in logs for service principals and confirm whether the failures are occurring under workload identity authentication rather than user sign in events.