Zero trust and the unmanaged app: why policy stops where integration stops

What does the standard say?

NIST SP 800-207, Zero Trust Architecture, published on 11 August 2020 by Rose, Borchert, Mitchell and Connelly, opens with a definition: "Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources." CISA's Zero Trust Maturity Model organizes the work into five pillars and three cross-cutting capabilities. Identity is central to both.

Where does the identity provider come in?

In most enterprises the practical policy engine for user access is the identity provider. Microsoft describes Entra Conditional Access as its Zero Trust policy engine, deciding on sign-ins using signals such as the user or group, location, device, application and risk. Other identity providers have equivalents. When a user signs in to an application through the identity provider, the policy applies.

What does the policy engine not see?

It sees only the requests that pass through it. Three kinds do not:

• Sign-ins to applications that are not integrated with the identity provider at all.
• Sign-ins that use an application's own local login, API tokens or legacy protocols even though SSO is configured.
• Actions by service accounts and integrations that authenticate directly to the application.

Push Security describes finding "hidden login paths that bypass SSO". Orchid Security lists shadow authentication paths among the findings it reports from inside applications. Both are describing requests the policy engine never evaluates.

Why does this matter for a zero trust program?

A maturity assessment that counts policies in the identity provider measures the integrated estate. It says nothing about the unintegrated part, which can be large. An honest assessment states the denominator: of the applications in use, how many does the policy engine actually decide for, and through which sign-in routes.

What closes the gap?

1. Find the applications that are not integrated. Discovery comes before policy.
2. For integrated applications, list every sign-in route and close the ones that bypass the identity provider where the application allows it.
3. For routes that must stay open, such as emergency logins, put a named custodian and logging on them.
4. Inventory service accounts and integrations, and give each an owner.
5. Report coverage alongside policy counts, so progress on one does not hide the other.

The classroom lesson on shadow authentication paths walks through step 2 for one application.

Sources