A non-marketplace app is a third-party integration that is installed or connected outside a formal software marketplace or approval channel. These apps may still be useful, but they often bypass the governance controls, security review, and privacy standards that organisations expect from curated marketplace integrations.
Expanded Definition
A non-marketplace app is an integration acquired and connected outside a curated approval channel, so its trust posture depends on local review rather than platform vetting. In NHI security, that distinction matters because the app may request API scopes, service-account credentials, or delegated tokens without the same screening expected from a formal marketplace listing. The term is often used alongside SaaS add-ons, browser extensions, internal bots, and custom connectors, but no single standard governs this yet. Definitions vary across vendors, especially when an app is “installed” through one product but functionally acts as a third-party integration in another environment.
For governance teams, the key issue is not whether the app is useful, but whether it enters the environment with documented ownership, scoped secrets, and revocation paths. A strong control baseline is to treat every non-marketplace app as an unreviewed trust boundary until its identity, data access, and operational dependencies are validated against guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is assuming “outside the marketplace” means “low risk,” which occurs when teams approve convenience integrations without checking the secrets, scopes, and offboarding process behind them.
Examples and Use Cases
Implementing non-marketplace app governance rigorously often introduces friction, requiring organisations to weigh integration speed against the overhead of review, logging, and credential control.
- Teams connect a custom ticketing or chat automation bot that uses a service account and long-lived token, making ownership and rotation requirements essential.
- A department installs a browser extension or desktop plugin that can read data from productivity tools, creating a shadow integration path outside central approval.
- Developers link a third-party AI assistant to internal repositories and issue trackers, similar to the risk patterns highlighted in the JetBrains Marketplace AI Plugin Campaign.
- An operations team uses a partner-built connector that authenticates with OAuth scopes broader than the use case requires, so access review must focus on delegated authority.
- Security teams compare the app’s requested privileges and data handling to the baseline expectations in the NIST control catalog before allowing production use.
These cases are especially relevant when the app is installed by an end user or business unit without a central procurement workflow, because the integration may function like an unofficial NHI that can later outlive its sponsor.
Why It Matters in NHI Security
Non-marketplace apps matter because they frequently become the hidden path by which secrets, tokens, and delegated access spread beyond governance reach. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is exactly the kind of outcome that unmanaged third-party integrations can accelerate. When an app is not tied to a formal marketplace, organisations often lose visibility into what credentials it stores, who approved it, and how to revoke it when the relationship ends. That creates direct risk for service accounts, API keys, and other NHI assets that are already difficult to inventory at scale. The broader problem aligns with the reality that 92% of organisations expose NHIs to third parties, raising supply chain concerns that are easy to overlook during business-led adoption.
This is why non-marketplace apps should be governed as supply-chain entry points, not just convenience tools. The right response is to require identity scoping, credential rotation, logging, and rapid deprovisioning before an integration is accepted into production, drawing on controls from NIST SP 800-53 Rev 5 Security and Privacy Controls and the NHI lifecycle guidance in Ultimate Guide to NHIs. Organisations typically encounter the real impact only after a token is abused or an integration is no longer supported, at which point non-marketplace app governance becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Unapproved integrations often lead to secret sprawl and weak NHI governance. |
| NIST CSF 2.0 | PR.AC-3 | Third-party app access must be authorized and monitored as an access-control decision. |
| NIST Zero Trust (SP 800-207) | SA-4 | Zero Trust requires validating each external integration before trust is extended. |
| NIST SP 800-63 | Delegated app access depends on strong identity assurance and credential handling. | |
| NIST AI RMF | AI-connected non-marketplace apps introduce governance and accountability risks. |
Inventory every app credential, restrict scope, and rotate or revoke secrets on a fixed schedule.
