Unauthorised Software

What makes unauthorised software risky

Unauthorised software usually becomes a security problem because it bypasses the organisation’s normal review, approval, and control processes. That means security teams may not know what data it touches, what permissions it uses, or whether it creates an unmanaged route into corporate systems. The main issue is not simply that the software is “unapproved”, but that its behaviour, dependencies, and data handling are outside governance.

In practice, this can weaken visibility across the environment. Tools installed by users or teams without review can duplicate sanctioned services, introduce unsanctioned data flows, or retain access long after the business need has changed. That makes it harder to enforce policy consistently and easier for sensitive information to move into places the organisation does not monitor well.

How unauthorised software creates shadow IT

Unauthorised software is one of the clearest technical signs of shadow IT. It often appears when users try to solve a business problem faster than the approved procurement or security process can support, but the result is a parallel technology stack that the organisation does not fully own. The danger is not only duplication, it is fragmentation of accountability.

When teams rely on unreviewed apps or services, ownership questions become ambiguous. Who approved it, who administers it, who reviews its access, and who removes it when it is no longer needed? Without those answers, the software can remain active well beyond its intended use, increasing the chance of stale accounts, orphaned integrations, or untracked data retention.

Security and compliance implications

Unauthorised software can create direct exposure through insecure configuration, weak authentication, excessive access, or undocumented integrations. Even if the software itself is legitimate, an organisation may be unable to verify how it stores data, logs activity, or handles credentials and tokens. That uncertainty matters because control failures are often hidden until an incident, audit, or access review exposes them.

It can also create compliance problems when regulated, contractual, or internal policy requirements depend on approved tooling and controlled data processing. If a service handles personal, financial, or confidential information outside the approved stack, the organisation may lose assurance over retention, residency, access, and security controls.

For broader control context, a baseline control catalogue such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because unauthorised software typically collides with access control, configuration management, auditability, and system integrity requirements.

Detecting and controlling unauthorised software

Detection starts with knowing what software should exist. Asset inventories, software allowlists, endpoint telemetry, cloud application discovery, and procurement records all help reveal tools that have bypassed formal review. Organisations also need to watch for unusual outbound connections, new browser-based services, local sync clients, and third-party plugins that extend access to corporate data.

Control is most effective when security and IT treat software approval as part of normal operational governance rather than a one-time exception process. The goal is to make approved tools easy to request and unapproved tools easy to identify, then reduce the incentive for users to work around the process by closing gaps in sanctioned services.

Risk and Threat Considerations

Unauthorised software matters because it often creates hidden trust paths, unknown data movement, and unmanaged access that defenders do not fully see. Attackers also benefit from these gaps, since shadow IT can expose weak authentication, stale integrations, and forgotten services that are less likely to be monitored or patched.

Failure mechanism: A user or team adopts an unreviewed application, service, or plugin, which then handles corporate data or access without the organisation’s normal security, logging, or lifecycle controls.

Impact: The organisation can lose visibility over data exposure, permissions, and retention, while also increasing the chance of policy violations, incident response blind spots, and persistent shadow IT risk.

Practitioner Guidance

Why practitioners should care: The practical problem is not only app sprawl, but unmanaged trust. If a tool is not in scope for review, it may also be out of scope for monitoring, access governance, incident response, and supplier oversight.

Governance implication: Ownership needs to be explicit from the point of approval through retirement. A software approval process should answer who sponsors the tool, who reviews risk, and who is accountable when the tool changes, is abandoned, or is discovered in use without approval.

Practitioner takeaway: Treat unauthorised software as a visibility and accountability problem first, then a technical control problem. The fastest way to reduce the risk is to make sanctioned alternatives discoverable, usable, and easier to adopt than shadow IT.

Related resources from NHI Mgmt Group

• What fails when organisations only scan endpoints occasionally for unauthorised software?
• How do you detect unauthorised remote access software such as UltraVNC on Windows?
• How should security teams handle exposed secrets in modern software pipelines?
• What is the difference between software supply chain risk and NHI risk?