COM activation is the process of creating and initialising a COM object so it can service requests. In Windows, activation can occur in-process or in a separate server process, and that distinction matters because out-of-process activation can move execution into a different security context.
Expanded Definition
COM activation is the Windows process that instantiates a com object and prepares it to handle calls, whether the object runs inside the caller’s process or in a separate server process. That distinction is central to NHI security because activation is not just object creation; it can also determine which security boundary, token, and runtime context will apply to the resulting component.
In practice, COM activation intersects with identity, privilege, and trust decisions that are often implicit. A caller may believe it is invoking a local component, while the activation path redirects execution to an out-of-process server with different permissions or attack exposure. This is why COM activation is best understood alongside access control, service identity, and launch permissions, not as a purely software-engineering detail. Windows component security guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant where activation pathways touch privileged services and managed credentials.
The most common misapplication is treating activation as harmless plumbing, which occurs when teams ignore the security context shift introduced by out-of-process servers.
Examples and Use Cases
Implementing COM activation rigorously often introduces operational overhead, requiring organisations to balance compatibility and isolation against packaging complexity and troubleshooting effort.
- A desktop application activates a local COM object in-process for performance, but the same class is later reconfigured to run out-of-process to reduce blast radius.
- A Windows service exposes a COM server that launches under a dedicated service identity, where launch permissions and token context must be reviewed as part of privileged access management.
- An enterprise automation tool invokes a COM component that reads or writes system resources, making the activation path a security control point rather than a simple runtime detail.
- An incident review traces unexpected behaviour to a COM server that was activated under a different security context than the calling application expected.
- For broader NHI governance context, the visibility and lifecycle issues described in Ultimate Guide to NHIs help explain why hidden execution paths matter when software components act like identities.
These scenarios align with identity assurance concepts in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where launch rights, service accounts, and privileged actions must be constrained.
Why It Matters in NHI Security
COM activation matters because the component being created may behave like an NHI-adjacent workload identity, with privileges, reach, and trust relationships that are easy to overlook. When teams misread activation behavior, they can unintentionally grant higher execution rights, expand the attack surface, or create hidden paths for code execution in a more privileged context. This is especially risky when COM servers are bound to long-lived service accounts or administrative tokens, because the object lifecycle becomes intertwined with identity governance.
NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and that pattern is directly relevant here: if a COM server activates with more authority than the caller expects, least-privilege assumptions break down quickly. The governance lesson is to treat activation policy, launch permissions, and server identity as part of the same control plane used for service accounts and secrets management. The security and lifecycle problems described in Ultimate Guide to NHIs are a useful analogue for understanding why unmanaged execution identities become hard to audit.
Organisations typically encounter this risk only after an unexpected privilege escalation, at which point COM activation becomes operationally unavoidable to investigate and contain.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Activation paths can expose hidden NHI privileges and launch permissions. |
| NIST CSF 2.0 | PR.AC-4 | Access control must govern which identity can launch and reach a COM server. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust requires explicit authorization even when components activate locally. |
| NIST SP 800-63 | AAL2 | Identity assurance concepts help frame strong service and component trust decisions. |
| OWASP Agentic AI Top 10 | A1 | Unexpected execution authority mirrors agentic tool-use and privilege risks. |
Inventory COM servers, restrict launch rights, and verify each activation context has only required privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
