What is the difference between a standards-based application and a non-standard application?

A standards-based application is built to work with identity protocols such as SAML or OIDC, so it can support federated authentication and single sign-on more naturally. A non-standard application was not designed for those protocols and often depends on usernames, passwords, or intermediary translation layers. The difference determines how easily modern access controls can be enforced.

What Makes the Two Application Types Different

The core difference is whether the application natively understands modern identity standards. A standards-based application can consume federated login flows, accept assertions or tokens from an identity provider, and fit into central access policies without custom translation. A non-standard application usually relies on local accounts or proprietary login logic, which makes federation, session control, and policy enforcement more brittle.

That difference shows up first in integration effort, but it quickly becomes an access-governance issue. Standards-based applications are easier to place under consistent authentication, lifecycle, and audit controls because the control plane is shared. Non-standard applications often require compensating patterns, such as password vaulting, header injection, reverse proxies, or custom connectors, each of which adds operational complexity and failure points.

In practice, teams usually discover the real difference when they try to centralise access and find that the application, not the identity platform, is the limiting factor.

How It Works in Practice

Standards-based applications typically delegate authentication to a trusted identity provider and then trust the resulting protocol exchange to establish the user session. That means the application can rely on well-understood message formats, token claims, and logout or session-expiry behaviour rather than inventing its own account model. In many environments, that also makes it easier to apply single sign-on, step-up authentication, and conditional access consistently across multiple applications.

Non-standard applications, by contrast, often force security teams to choose between weaker direct login patterns and wrapper controls that sit in front of the application. The most common patterns are:

Local usernames and passwords with manual account administration.
Credential translation through a proxy or access gateway.
Custom integrations that map modern identity assertions into legacy session handling.

Those patterns can work, but they shift risk into the translation layer. The application may still be functionally usable while remaining disconnected from central policy, making revocation, logging, and review harder than they appear on paper. That matters most when the application holds sensitive data, supports privileged workflows, or sits in a critical operational path.

The practical test is simple: if the application can participate directly in federated authentication and policy enforcement, it is materially easier to govern; if it cannot, the surrounding controls become part of the security design rather than an implementation detail. These controls tend to break down when a legacy application mixes direct local login with partial federation, because inconsistent session state creates blind spots for both access review and incident response.

Common Variations and Edge Cases

Tighter standardisation often increases upfront engineering effort, so teams have to balance immediate compatibility against long-term access control consistency. Not every application can be modernised in the same way, and some legacy systems can only be brought into the control plane through wrappers or managed exceptions.

One common edge case is a hybrid application that supports modern login for some users but still keeps local accounts for admins, automation, or break-glass access. That is operationally convenient, but it creates two trust paths with different review and revocation requirements. Another edge case is an externally hosted application that claims to support standards but exposes only partial protocol coverage, such as authentication without robust logout, provisioning, or role mapping.

The best practice is to evaluate the full access lifecycle, not just initial sign-in. A system that authenticates cleanly but cannot be deprovisioned, audited, or constrained reliably behaves like a non-standard application from a governance standpoint, even if its login screen looks modern.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL / federation guidance — Digital Identity Guidelines	Covers federated authentication and modern identity assurance for applications.
Recommendation — Use federated identity patterns that meet the required assurance level for the application.
CIS Controls v8	6 — Access Control Management	Covers centralising and reviewing access paths across applications.
Recommendation — Enforce least privilege and remove direct local access paths where possible.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Applies because the subject is about how applications participate in identity and access control.
Recommendation — Map application access paths to central identity and access control processes.

Practitioner Guidance

What to prioritise: Classify the application by its weakest access path, not by its marketing claims. If one path still depends on local credentials, manual exceptions, or a translation layer, treat that path as the governing design constraint.

What to verify: Confirm whether the application supports federation end to end, including session expiry, role mapping, deprovisioning, and audit evidence. A partial integration is often enough to reduce friction, but not enough to remove the need for compensating controls.

Decision rule: If the application can enforce central authentication and revocation without a custom wrapper, treat it as standards-based for governance purposes. If not, require explicit ownership for the exception, plus a review plan for rotation, logging, and eventual replacement.

Practitioner takeaway: The important question is not whether an application can log a user in, but whether the organisation can govern access to it at scale without special handling.