Who is accountable when a malicious connected app is authorised by an employee?

The customer is accountable for governing who can approve apps, what scopes are allowed, and how risky integrations are reviewed. The platform may provide the controls, but the operating model determines whether a fraudulent authorisation becomes a breach or is blocked before access is granted.

Why This Matters for Security Teams

When an employee authorises a malicious connected app, the failure is rarely just “bad judgment.” It is usually a governance gap in app approval, scope review, and post-authorisation monitoring. That makes the accountability question operational, not theoretical: teams need to know who defined the approval path, who can grant consent, and who is responsible for detecting abuse after consent has been issued. NHI Mgmt Group’s Ultimate Guide to NHIs shows how often identity controls fail when secrets, service accounts, and third-party access are not managed as a system.

This matters because connected apps often inherit broad access through OAuth scopes, API tokens, or delegated permissions. The platform may validate the request, but it does not decide whether the business should trust the integration. Security teams commonly assume the vendor, the identity provider, or the end user is the accountable party, and that confusion slows containment. Current guidance from the NIST Cybersecurity Framework 2.0 points back to governance, risk ownership, and access control as organisational responsibilities. In practice, many security teams encounter abuse only after a consenting employee has already exposed data or granted persistent access to a fraudulent app.

How It Works in Practice

Accountability is usually shared, but not equal. The organisation is accountable for the policy environment that makes malicious consent possible, while the employee is accountable for following approved procedures, and the platform provider is accountable for offering controls that can express those procedures. The practical question is whether consent is treated as a low-friction user action or a security decision that requires business review, scope restrictions, and monitoring.

Most mature programs separate the approval of an app from the act of user consent. A strong operating model usually includes:

• Pre-approval for common integrations, with only low-risk scopes allowed by default.
• Restricted consent rights so not every employee can authorise high-impact access.
• Scope review that checks whether the app requests data or actions beyond its stated purpose.
• Periodic access review and revocation for apps that are no longer used.
• Alerting for unusual consent events, such as new publishers, rare scopes, or mass grants.

This is where NHI governance becomes essential. OAuth tokens, refresh tokens, API keys, and service accounts behave like non-human identities once they are issued, so they need the same visibility and lifecycle controls described in the Ultimate Guide to NHIs. The organisation must define who can approve apps, what scope categories are acceptable, and which integrations require security sign-off before consent is permitted.

Standards bodies generally align on the principle that access decisions should be governed, monitored, and revocable, but there is no universal standard for exactly where the approval threshold should sit. Current guidance suggests mapping app consent to least-privilege and zero-trust principles rather than relying on one-time user discretion. These controls tend to break down in large SaaS estates where users can self-install third-party apps faster than security teams can review publisher risk.

Common Variations and Edge Cases

Tighter app consent controls often increase friction, requiring organisations to balance user productivity against blast-radius reduction. That tradeoff becomes sharper in environments where marketing, sales, or operations teams rely on many niche integrations and expect fast self-service access.

One edge case is delegated admin consent, where a privileged user authorises an app for the whole tenant. Another is bring-your-own workflow tooling, where employees connect personal automation platforms to corporate data sources. A third is consent phishing, where a malicious app looks legitimate and asks for access that appears routine. In these cases, the employee may be the one who clicks, but the real accountability still sits with the organisation’s approval model, because it decided whether the risk was detectable, preventable, or both.

For security leaders, the right question is not only “who clicked approve?” but “who had authority to allow that approval path to exist?” That is why NHI Mgmt Group treats third-party integrations as part of the identity perimeter, not as a separate SaaS convenience layer. The Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both support the same operational conclusion: consent without governance is just an exposed control point.

Related resources from NHI Mgmt Group

• Who is accountable when forged DNS responses redirect users to malicious sites?
• Who is accountable when a connected app grants unauthorised access to data?
• Who should be accountable when an employee buys an unsanctioned SaaS app?
• Who should be accountable when an agent makes a high-risk decision?