Extensions are globally defined add-ons that let organisations integrate with and extend cloud platform capabilities. They are subscribed to by an organisation, carry permissions, and can be private or public. This model allows controlled capability expansion while keeping access boundaries tied to organisational approval and permissions.
Expanded Definition
LimaCharlie Extensions are platform add-ons that organisations subscribe to in order to extend cloud-hosted security capabilities without replacing the core service. The defining feature is not just that they add functionality, but that they do so through an organisational subscription model with explicit permissions, which makes extension governance part of the platform’s access model.
That boundary matters. An extension is not the same as a generic integration, because it is usually packaged for repeated use, governed centrally, and constrained by the organisation’s approval and entitlement model. Public extensions broaden availability, while private extensions usually narrow distribution to a specific tenant or use case. In practice, the security question is not simply what the extension does, but who can subscribe to it, what it can reach, and which permissions it inherits once enabled.
For a wider control perspective, organisations often map this kind of capability expansion to the access and configuration discipline described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where approval, least privilege, and change control are part of the operating model.
Examples and Use Cases
- A security team subscribes to a public extension that enriches telemetry before forwarding events into its detection pipeline.
- An internal operations group publishes a private extension to standardise enrichment logic across multiple business units.
- An organisation enables an extension that connects the platform to an external workflow system, then limits it to a tightly defined permission set.
- A platform administrator reviews whether an extension should be enabled globally or only for a specific tenant because the permission scope differs.
- A team tests an extension in a staging environment first, because extension behaviour can change how data moves between services.
The main trade-off is convenience versus control. Extensions reduce custom engineering effort, but they also create another layer of platform dependency that must be evaluated for trust, scope, and maintainability.
Security Implications
Misunderstanding an extension model can lead organisations to grant more capability than intended. Because extensions are subscribed to by an organisation and may carry permissions, a poorly reviewed add-on can widen access to telemetry, workflows, or downstream systems that were not meant to be broadly exposed.
The failure mode is often subtle. The extension may work exactly as expected from a functional perspective while still introducing over-permissioned access, opaque data handling, or hidden operational coupling. If the approval process is weak, a private extension can become a shadow dependency; if the permission model is too broad, a public extension can become a repeatable path to overreach across environments.
Practitioners should watch for extension sprawl, unclear ownership, and permissions that are broader than the extension’s documented purpose. Those symptoms usually indicate that capability expansion has outrun governance.
Domain and Governance Relevance
LimaCharlie Extensions matter in platform security because they change how organisations consume new capability. The important governance issue is that functionality is no longer just a build-versus-buy decision; it becomes a controlled subscription and permission decision that affects who may introduce behaviour into the environment.
That makes the term relevant to security operations, vendor risk review, and platform administration. The extension model can improve standardisation and reduce bespoke code, but only if organisations treat subscription approval, permission scope, and lifecycle ownership as first-class controls rather than administrative afterthoughts.
For NHIMG’s identity and access lens, the key shift is that the extension itself behaves like a governed capability boundary. If the platform exposes permissions to an add-on, then approval, scope, and revocation discipline become part of the trust model, even when the extension is not a human account. That is where operational control, not just technical functionality, determines whether the model remains safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Extensions rely on subscription approval and scoped permissions. |
| 15 — Service Provider Management | Public or private extensions introduce third-party or internal supply-chain dependency. | |
| Recommendation — Enforce access approval and remove extension permissions that exceed their documented purpose. Review extension providers and validate their security obligations before subscription. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Management | Extension enablement depends on assigning and limiting platform permissions. |
| PR.IP-3 — Configuration Change Control Processes | Extensions change platform behaviour and should follow controlled approval. | |
| Recommendation — Limit extension privileges to the minimum access required for the approved use case. Treat extension enablement as a controlled configuration change and track ownership. | ||
| MITRE ATT&CK | T1210 — Exploitation of Remote Services | Extensions can create new remotely reachable trust paths if overexposed. |
| Recommendation — Inspect extension-enabled remote paths for abuse and restrict unnecessary exposure. | ||
