What breaks when organisations secure logins but ignore app approvals?

Why This Matters for Security Teams

App approvals are often treated as a convenience layer, but for SaaS platforms, OAuth grants, and agent-connected workflows, they are frequently the real authorization boundary. If a user can be tricked into approving a malicious integration, or if a trusted token is reused beyond its intended scope, MFA on the login page no longer protects the resource. That gap is central to NHI governance because the approval event often creates the non-human identity, the credential, and the access path at the same time.

The practical risk is that organisations harden sign-in while leaving consent, token scope, and app lifecycle controls under-reviewed. Current guidance suggests this is a common blind spot in Zero Trust programs: authentication proves who signed in, but it does not automatically validate what an application is allowed to do after consent. NHI Mgmt Group notes in the Ultimate Guide to NHIs that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why approval governance belongs in the same control set as login security. In practice, many security teams encounter the breach only after the approved app has already expanded access, rather than through intentional review of the consent flow.

How It Works in Practice

Secure login controls defend the human entry point, but app approvals govern what happens after authentication. In many environments, a user signs in with MFA, then grants an application delegated permissions through OAuth consent, marketplace install, API token exchange, or admin approval. At that moment, the application receives durable access that may outlive the session and bypass future login prompts. This is why the approval path must be treated as a privileged control surface, not a user experience step.

Good practice is evolving toward layered consent governance. That usually includes:

• restricting who can approve apps and what scopes they can grant;
• reviewing publisher trust, redirect URIs, and requested permissions before approval;
• using conditional access and policy checks for high-risk or unverified applications;
• time-limiting tokens and revoking grants when the business need ends;
• monitoring for consent spikes, unusual scopes, and token reuse across tenants.

This approach aligns with the NIST Cybersecurity Framework 2.0, which emphasises access control, monitoring, and continuous response rather than one-time authentication events. It also fits the broader NHI lifecycle described in the Ultimate Guide to NHIs, where visibility and revocation matter as much as issuance. Where organisations approve apps without scope review, token inspection, or offboarding, the controls tend to break down when a trusted integration is compromised or a consented app is repurposed for lateral access because the login layer is no longer involved.

Common Variations and Edge Cases

Tighter approval controls often increase administrative overhead, requiring organisations to balance faster user onboarding against stronger scrutiny of delegated access. That tradeoff becomes sharper in SaaS-heavy and AI-assisted environments, where employees expect rapid app enablement and autonomous tools may request broad permissions to function effectively.

There is no universal standard for this yet, but current guidance suggests treating certain approvals as high-risk by default. Examples include apps that request offline access, mail-read scopes, directory write permissions, or cross-tenant access. Agentic and automation scenarios are especially sensitive because the approved app may not behave predictably after installation. Security teams should also watch for “shadow approvals” in developer tools, CI/CD pipelines, and admin consoles, where a trusted token or service principal can be reused long after the original review.

For organisations with mature IAM, the next step is not just stronger login assurance. It is governance over consent, token scope, and lifecycle revocation so that app approvals cannot become the hidden privilege-escalation path.

Related resources from NHI Mgmt Group

• Why can a single SaaS app create such a large blast radius?
• What breaks when organisations ignore session security after MFA?
• What breaks when payment fraud controls assume a human is always the actor?
• What breaks when session revocation is weak in production apps?