Extending a directory only to web apps leaves gaps because modern IAM must cover endpoints, servers, and network access as well as SaaS. When access governance stops at browser-based applications, teams usually add separate tools for other resources, which increases cost, admin effort, and inconsistency. A complete programme needs a credential model that federates across the full environment, not just one access layer.
Why the directory-only model leaves the programme fragmented
A directory can centralise sign-in for browser apps, but IAM is broader than application login. Once endpoints, servers, network access, and service-to-service access sit outside that model, teams end up with parallel controls, duplicate policies, and different audit trails. That fragmentation is what makes the programme feel “incomplete” even when the directory is well run.
The real issue is scope. A modern programme has to account for human users, privileged admins, non-human workloads, device trust, and the resources they reach. If one access layer is governed while others are handled by separate tools, the organisation no longer has one consistent control plane for identity, entitlement, and review.
That is why a directory-only approach often solves authentication for a slice of the estate, but not the operating model around it. The gaps show up in joiner-mover-leaver processes, access certification, privileged access, and visibility into where credentials or federated trust actually grant access.
What gets missed when IAM stops at web apps
Web apps are only one consumer of identity, so a browser-centric design leaves out the places where abuse can be most damaging. Endpoints and servers often need device or host trust, network access may need conditional enforcement, and cloud or platform components may rely on roles, tokens, certificates, or workload identities rather than an interactive user session. A complete programme has to federate across these access patterns, not bolt them on later.
When those surfaces are excluded, organisations usually compensate with separate point tools for VPN, endpoint login, server administration, cloud permissions, or secrets handling. That creates inconsistent policy expression, weaker lifecycle control, and more manual exceptions. It also makes it harder to answer a basic audit question: who or what can reach which resource, under what authority, and with what revocation path?
For a deeper view of the lifecycle and governance problem behind that fragmentation, the IAM and IGA Basics guide shows why access governance has to cover provisioning, reviews, and entitlement control across both people and machines. The same principle is reflected in the Ultimate Guide to NHIs, What are Non-Human Identities, which helps frame why workload and service identities cannot be treated as an afterthought.
What a complete programme has to federate
A complete IAM programme does not mean one product for everything. It means one coherent identity model that can extend trust across SaaS, endpoints, servers, infrastructure, and non-human access without losing governance. In practice, that usually means a common source of truth for identity attributes, consistent policy decisions, strong federation, and lifecycle controls that apply whether the subject is a person, device, or workload.
It also means choosing controls that match the access type. Browser SSO, device login, server administration, cloud roles, and API access each have different risk profiles, so the programme should not pretend one mechanism is enough. The point is to unify oversight and revocation, not force every resource through the same runtime path.
The Identity Security Programme Guide is useful here because it treats IAM as an operating model rather than a login project. For workload and service access specifically, the Cloud Workload Identity Guide shows why keyless federation and temporary credentials are better programme building blocks than long-lived static secrets. In cloud environments, the Cloud PAM and CIEM Guide adds the entitlement and privilege side that directory-only approaches often miss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | IAM must span cloud identities, privileges, and federation beyond web apps. |
| Recommendation — Apply IAM controls to govern identities, federation, and access across cloud and non-web resources. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service, Device, and Other Non-Organizational Users) | The question includes non-web access paths, including service and machine access. |
| IA-5 — Authenticator Management | Completeness depends on managing credentials and tokens across all resources, not only web SSO. | |
| Recommendation — Use IA-9 to authenticate non-organizational and machine access paths consistently. Manage authenticators and secrets centrally so revocation and rotation stay consistent. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Federation across endpoints, servers, and network access aligns with never-trust, verify access decisions. |
| Recommendation — Apply zero trust principles to verify access continuously across all access layers. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Non-web workloads often fail when static credentials persist outside the directory model. |
| Recommendation — Replace long-lived non-human secrets with short-lived or federated alternatives. | ||
Practitioner Guidance
What to prioritise: define the access surfaces the directory is not governing today, then map each one to an owner, a lifecycle path, and a revocation mechanism. If you cannot quickly show how a server, endpoint, or workload access path is reviewed and removed, the programme is still partial.
What to verify: check whether access reviews cover only interactive users or also service identities, cloud roles, privileged admin paths, and device trust. A credible programme should let you trace an entitlement from issuance to removal across all of those paths.
Common mistake: treating SSO coverage as proof that IAM is “done”. SSO improves user convenience and browser governance, but it does not by itself solve privileged access, device access, infrastructure access, or machine-to-machine access.
What good looks like: the organisation can federate identity across major access layers, enforce consistent policy, and retire access centrally without depending on separate cleanup in every platform team.
Practitioner takeaway: the test is not whether the directory authenticates users well, it is whether identity, privilege, and revocation still behave coherently once you leave the browser.
