How should security teams extend zero trust to nonstandard applications that do not support SAML, SCIM, or OIDC?

Why This Matters for Security Teams

zero trust breaks down quickly when a business-critical application cannot support SAML, SCIM, or OIDC. If the app is treated as an exception, teams often fall back to shared accounts, hand-built scripts, and long-lived secrets, which reintroduce standing access through the back door. NIST’s NIST SP 800-207 Zero Trust Architecture is clear that trust must be continuously evaluated, but nonstandard applications rarely offer the native hooks needed to do that cleanly.

The real issue is not protocol support alone. It is whether identity, policy, and revocation remain enforceable when the application sits outside the standard IAM stack. NHIMG’s Ultimate Guide to NHIs — Standards shows how often organisations still store secrets in vulnerable places and struggle with offboarding, which makes disconnected apps especially risky. In practice, many security teams discover the access problem only after a credential has been reused, shared, or left active long after the original business need ended.

How It Works in Practice

The practical goal is to wrap the application with identity controls that compensate for missing standards, rather than assuming the app will eventually become modernised. That usually means centralising policy at the access layer, vaulting credentials, and forcing each account to be tied to an owner, purpose, and review cycle. Where possible, access should be brokered through a gateway, reverse proxy, PAM workflow, or service wrapper that can enforce step-up authentication, session recording, and automated expiry.

For applications that cannot speak modern federation, the identity pattern should shift from static entitlement management to controlled issuance and revocation. That includes:

• Using a vault or broker to issue short-lived credentials instead of embedding passwords or API keys in code.
• Separating human admin access from application service access, with different approval paths and logging.
• Requiring periodic recertification for every standing account that cannot be automated.
• Recording usage logs centrally so access reviews are evidence-based, not checkbox-based.
• Applying the same offboarding standard used for modern apps, even if the technical enforcement is compensating rather than native.

NHIMG’s Guide to SPIFFE and SPIRE is useful here because it illustrates the broader shift toward workload identity and cryptographic proof of identity, even when older apps cannot consume those tokens directly. The control objective is still zero trust: authenticate strongly, authorise narrowly, log continuously, and revoke quickly. These controls tend to break down when a legacy application hardcodes local admin accounts and provides no API, proxy, or vault integration because revocation then depends on manual human action.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance security gains against change-management friction and application stability. That tradeoff is most visible in legacy ERP, industrial, and vendor-managed systems where owners resist proxying or where a full rebuild is not realistic. Current guidance suggests that a compensating-control model is acceptable, but there is no universal standard for this yet, so teams should document the risk decision and revisit it on a fixed schedule.

Some environments need additional caution. Third-party hosted tools may limit logging or revocation, which means access reviews and credential rotation become the main safeguards. Shared service accounts should be treated as transitional risk, not a steady-state design. NHIMG’s Schneider Electric credentials breach and OneLogin API Key Vulnerability both reinforce the same lesson: when secrets are long-lived, exposed, or poorly governed, the trust boundary collapses even if the application itself never supported federation.

For nonstandard applications, the right question is not whether they support SAML or OIDC, but whether access can still be made time-bound, attributable, and revocable. If those three conditions cannot be met, current best practice is to treat the app as a high-risk exception and reduce its privilege footprint until it can be modernised or retired.

Related resources from NHI Mgmt Group

• How should security teams extend Zero Trust across hybrid and offline Microsoft environments without weakening phishing resistance or MFA resilience?
• How should security teams extend Zero Trust controls into the browser for managed and unmanaged devices?
• How should security teams govern applications that do not support SCIM or SAML?
• How should security teams implement authorization in Zero Trust environments with many apps and APIs?