Launch and Activation Permissions are DCOM permissions that control who can start a COM server and who can connect to it after it starts. They are set separately from access permissions, and they govern remote or local activation of the component.
What Launch and Activation Permissions Do
Launch and Activation Permissions are the DCOM control point that decides who can start a COM server and who can connect to it after it starts. They are separate from access permissions, so the “who may launch” decision is not the same as the “who may use it once running” decision. That separation matters because activation is often the first gate into a sensitive component.
In practical terms, these permissions shape whether a component is available only to local administrators, to a narrow application set, or to broader users and remote callers. If they are configured too broadly, a service that was meant to be tightly controlled can be started by unintended principals, which expands the trusted surface before the component even begins processing requests.
How Launch and Activation Permissions Work in DCOM
DCOM distinguishes launch permissions from access permissions so operators can control two different moments in the component lifecycle. Launch and activation govern the start action itself, including remote activation, while access permissions govern the ability to interact with an already running server. That split is useful when a server is safe to use only after it has been started by a trusted process or account.
The permissions can be assigned at different scopes, including machine-wide defaults and per-application settings. In a large Windows estate, that means the effective activation policy may come from inheritance, local override, or application-specific configuration, so an apparently simple permission issue can actually reflect several layers of policy.
Because COM servers often underpin legacy management tools, industrial software, and line-of-business applications, launch policy can affect both functionality and containment. A restrictive configuration can break expected activation paths, while an overly permissive one can let unexpected users or systems bring a server online.
Why the Separation From Access Permissions Matters
Keeping launch and access separate prevents a common mistake: assuming that if a caller can reach a component, it should also be able to start it. In reality, start authority is usually more sensitive than use authority because launching a server can trigger code execution, resource allocation, network listeners, or privileged actions that would not occur if the component remained stopped.
The distinction also matters for troubleshooting. A user may be blocked at activation time even though the component’s runtime permissions would otherwise allow interaction, or the reverse may be true. That makes DCOM permission review a two-step exercise: first confirm who can instantiate the server, then confirm who can interact with it afterward.
For hardening guidance on the broader DCOM model, including how launch and access permissions sit alongside authentication settings and service accounts, see the OPC Classic and DCOM Hardening Guide. It is especially relevant where legacy industrial or remote management components still rely on DCOM activation.
Common Security and Operational Pitfalls
The biggest security issue is overbroad activation rights. If too many users, groups, or remote systems can launch a server, that server may become reachable in ways the application owner never intended. Launch permissions are therefore a control on exposure, not just a configuration detail.
A second pitfall is assuming that the same principals should always control both launch and access. That assumption often fails in production, where a tightly controlled service may need one set of operators to start it and a different set of users to consume its functionality. Treating the two permissions as interchangeable can create either outages or unnecessary privilege.
Legacy environments add another layer of risk because DCOM configuration is often inherited, copied between hosts, or left at defaults. In those cases, the real exposure is not just the permission entry itself, but the false confidence that the server is already constrained when it may actually accept broader activation than expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Launch rights should be limited to the smallest set of trusted callers. |
| IA-2 — Identification and Authentication (Organizational Users) | Activation decisions depend on authenticated callers before launch is granted. | |
| CM-6 — Configuration Settings | Launch and activation permissions are configuration state that must be standardized and controlled. | |
| Recommendation — Restrict DCOM activation to the minimum principals needed to start the server. Require authenticated users and admins before granting activation privileges. Baseline and review DCOM activation settings as part of secure configuration management. | ||
| CIS Controls v8 | CIS-5 — Account Management | Activation permissions are tied to which accounts and groups may start sensitive services. |
| Recommendation — Review which accounts and groups can activate DCOM servers and remove unnecessary entries. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | DCOM activation permissions are a security-relevant configuration that needs controlled change. |
| Recommendation — Track, approve, and review DCOM permission changes under formal configuration control. | ||
Practitioner Guidance
What to watch for: Review launch and activation policy whenever a DCOM server is Internet-facing, remotely administered, or used by multiple trust zones. The key question is who can cause the component to start, because that is the point at which an apparently dormant service becomes an active attack surface.
Governance implication: Separate ownership of launch rights from runtime access rights in your administrative model. That makes it easier to spot when a component needs one group to activate it, another to operate it, and a smaller privileged set to change its configuration.
Practitioner takeaway: Treat launch permissions as a privilege boundary, not a convenience setting, and verify them alongside the component’s access permissions whenever you harden or audit DCOM-enabled systems.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org