Potentially Unwanted Program

Expanded Definition

A potentially unwanted program, or PUP, is software that may run as advertised while still being undesirable because of how it is packaged, installed, or monetised. In NHI security contexts, the term matters because the same delivery patterns that bring PUPs onto endpoints can also introduce credential theft, browser injection, or persistence mechanisms that affect service accounts and other NHIs.

Definitions vary across vendors. Some security tools treat PUP as a broad policy category for adware, toolbars, bundled installers, and system optimisers, while others reserve stronger labels for code that also exhibits overtly malicious behaviour. For governance purposes, the useful distinction is not whether the software "works", but whether user consent, supply chain trust, and operational impact are cleanly established. That makes PUP analysis relevant to NIST SP 800-63 Digital Identity Guidelines when software distribution influences identity assurance and enrollment integrity.

The most common misapplication is dismissing a PUP as harmless simply because an installer completed successfully, which occurs when teams ignore bundled components, hidden persistence, or altered trust chains.

Examples and Use Cases

Implementing PUP detection rigorously often introduces friction, requiring organisations to weigh cleaner endpoints and reduced exposure against more user prompts, support tickets, and false positives.

• A remote-access utility is bundled with a browser extension and an updater that changes proxy settings without obvious disclosure, creating a trust issue even if the main app is legitimate.
• An installer drops a system cleaner alongside the requested application, then requests broad permissions that exceed the software’s stated purpose and complicate endpoint governance.
• A desktop client stores API keys or session tokens in locations later surfaced by a suspicious add-on, which can turn a seemingly low-severity PUP into an NHI exposure path.
• A contractor package uses a manipulated download mirror or repackaged installer, echoing the kind of trust-chain weakness highlighted in the Schneider Electric credentials breach.
• Security teams classify a borderline tool as a PUP while validating whether it aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls for software inventory, least functionality, and configuration control.

In mature environments, PUP review also becomes part of software allowlisting, where the issue is less about malware signatures and more about whether the installation path, telemetry, or bundled defaults create unacceptable operational drift.

Why It Matters in NHI Security

PUPs matter in NHI security because they often arrive through the same channels used to deploy admin tools, developer utilities, and automation clients that handle secrets, tokens, and certificates. Once those channels are trusted, a bundled component can alter browser sessions, capture credentials, or weaken endpoint controls that protect privileged workflows. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which underscores how quickly a seemingly minor software decision can become an identity incident when secret handling is involved. The broader risk is not limited to the workstation, because manipulated installers can seed persistence that later affects service accounts or CI/CD access. This is why NHI governance treats software provenance as part of identity assurance, not just endpoint hygiene. A PUP can also obscure attribution during incident response, since defenders must separate legitimate functionality from hidden add-ons, telemetry, or credential-access behaviour. Organisations typically encounter the real impact only after a secrets leak, account abuse, or endpoint compromise, at which point PUP classification becomes operationally unavoidable to address.

That pattern is visible in cases where an installer path, not the application itself, becomes the entry point for compromise, and where post-incident analysis starts by tracing how software reached a trusted device in the first place.

Related resources from NHI Mgmt Group

• What does a mature secrets governance program need to cover?
• What is the difference between a bug bounty program and a vulnerability disclosure policy?
• What is the difference between DLP and DSPM in a modern program?
• How should organisations respond when a major IGA program cannot be completed at once?