Bundled availability means a project is included with the Curity Identity Server rather than maintained as a separate external distribution. The code is compiled into binary form and delivered through the product release process. That changes update handling, support boundaries, and how customers manage change when the component is used in production.
Expanded Definition
Bundled availability describes a delivery model where a capability is shipped as part of the Curity Identity Server release rather than maintained as a separately deployed external distribution. In practice, the bundled component inherits the product’s release cadence, packaging, and support boundaries, which changes how teams assess versioning, rollback, and operational ownership. This matters in NHI and IAM work because the availability model affects whether a control is treated as a product feature, an internal dependency, or an independently governed service. Definitions vary across vendors when a bundled capability behaves like a plugin, but no single standard governs this yet; practitioners should focus on release responsibility and change control rather than labels alone. For governance context, the NIST Cybersecurity Framework 2.0 is a useful reference point for mapping delivery choices to asset management and change management expectations. The most common misapplication is treating bundled availability as if it were fully independent software, which occurs when teams assume separate patching, support, and lifecycle ownership that the product does not actually provide.
Examples and Use Cases
Implementing bundled availability rigorously often reduces integration effort, but it also creates tighter coupling to the vendor release cycle, requiring organisations to weigh simpler deployment against less deployment autonomy.
- A platform team upgrades the identity server and receives the bundled capability automatically, avoiding a separate install but inheriting the same maintenance window.
- A security team documents the bundled component as part of the identity product inventory rather than as a standalone service, which clarifies ownership during incident response.
- A change advisory board reviews the release notes as a single package because the bundled feature cannot be patched independently without the parent product update.
- An operations team uses the bundled feature in production only after confirming support obligations and rollback procedures, following guidance from the DeepSeek breach lesson that hidden dependencies can amplify exposure when release discipline is weak.
- A governance team compares the bundled model to externally distributed services and decides whether the operational convenience justifies reduced flexibility in emergency remediation.
Why It Matters in NHI Security
Bundled availability affects how quickly identity-adjacent capabilities can be patched, audited, or removed when risk changes. In NHI environments, that matters because secrets handling, token flows, and agent access pathways often depend on adjacent components that must stay aligned with the core identity release process. Misunderstanding the bundled model can lead to unsupported forks, delayed remediation, or duplicated controls across teams that believe they own the same capability separately. That is especially relevant when organisations are already struggling with secrets governance: The State of Secrets in AppSec reports an average of 6 distinct secrets manager instances, a pattern that shows how fragmentation weakens centralized control and complicates lifecycle management. The same logic applies when a bundled component is treated as if it were independently governed. Security leaders should align release management, support escalation, and production change approval with the parent product, while still tracking the bundled function as a distinct risk surface. Organisational resilience also depends on recognising that availability is not just uptime, but the ability to replace or retire a component under pressure. Teams often discover the operational cost only after an outage, at which point bundled availability becomes impossible to ignore.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-5 | Delivery dependencies must be governed as part of supply chain and change oversight. |
| NIST Zero Trust (SP 800-207) | SC-7 | Bundled identity components still influence trust boundaries and protected pathways. |
| OWASP Non-Human Identity Top 10 | Bundled delivery changes how NHI dependencies, secrets, and lifecycle risk are managed. |
Treat bundled components as governed product dependencies with explicit release and escalation ownership.
