Default Launch and Access Permissions

What Default Launch and Access Permissions Do

Default Launch and Access Permissions are the baseline DCOM security settings that Windows uses when a COM application has not defined its own launch or access rules. In practice, they decide who can start a component and who can connect to it, until a more specific per-application rule overrides the default.

This matters because DCOM is not just a configuration detail, it is an operating permission boundary. If the baseline is too open, every uncustomised COM application inherits that exposure; if it is too tight, legitimate services and management tools can fail in ways that are hard to diagnose.

Why DCOM Defaults Matter

DCOM default permissions are system-wide policy, so they affect many components at once rather than a single application. That makes them a common root cause for broad compatibility issues, unexpected access denials, or inherited overexposure across older Windows estates and industrial or line-of-business software that still depends on COM activation.

The important design point is inheritance. Administrators often assume application-specific settings always exist, but many components rely on the system defaults. Where an application does define its own permissions, those settings take precedence, which means you need to understand both the global baseline and the per-application exception path.

How They Shape Access and Launch Behaviour

Launch permission controls whether a principal can activate a COM server, while access permission controls whether it can connect after activation. That distinction matters operationally because an identity may be allowed to start a component but still be blocked from using it, or the reverse. Troubleshooting requires knowing which side of the boundary is failing.

Because these permissions sit beneath the application layer, they often interact with service accounts, local administrators, remote callers, and legacy integration accounts. The effect is cumulative: a weak default can silently broaden exposure, while an over-restrictive one can break automation, remote administration, or dependent services without any change to the application itself.

Common Failure Modes and Operational Impact

The most common failures are unintended openness, inherited denial, and configuration drift. An organisation may believe it hardened one application, while the actual risk remains in the underlying default permission set that still applies to many other COM servers.

In Windows environments, the practical consequence is often intermittent and application-specific failure: one component starts normally, another returns access errors, and a third behaves differently after a patch, GPO change, or system migration. That is why DCOM permission changes should be treated as a platform control, not a one-off app tweak.

Practical Security Context

For a security team, the value of this term is that it identifies a baseline control point for COM activation and remote component access. The baseline should be reviewed alongside the applications that inherit it, because default permissions can become the hidden policy that determines whether legacy COM services are open, blocked, or inconsistently governed.

When investigating exposure, it helps to compare the default permission set with the subset of applications that override it, especially in environments where DCOM remains enabled for administrative tooling, OT software, or older business applications. The OPC Classic and DCOM Hardening Guide is useful here because it frames launch and access permissions in the context of real DCOM hardening work.

Risk and Threat Considerations

Weak default DCOM permissions can create broad, inherited exposure across many applications, especially where legacy software depends on system-wide settings rather than its own explicit policy. The security problem is not just accidental openness, but also the difficulty of spotting which components inherit the risky baseline.

Failure mechanism: If default launch or access permissions are too permissive, a caller may activate or connect to COM components that were never meant to be broadly reachable, creating an unnecessary attack surface or privilege boundary crossing.

Impact: The result can be unauthorized component use, lateral movement opportunities, or disruption when a hardening change is applied without mapping which services still depend on the inherited DCOM baseline.

Practitioner Guidance

Governance implication: Treat these settings as a shared platform policy, not a hidden local preference. Review the default DCOM launch and access permissions together with the applications that inherit them, then document which components rely on the baseline and which define their own exceptions.

What to watch for: Pay attention when legacy applications, remote administration workflows, or OT and industrial components begin failing after a security change. That pattern often indicates the default permission set is carrying more operational weight than teams expected.

Practitioner takeaway: The safest DCOM posture is one where the inherited baseline is explicitly known, intentionally constrained, and validated against the actual component inventory.

Related resources from NHI Mgmt Group

• What happens when Azure DevOps access is managed only through default groups and inherited permissions?
• What is the difference between reducing default repository permissions and relying on periodic access reviews?
• What breaks when a default cloud service account has broad project permissions and full API access in Google Cloud?
• What is the difference between a controller creating pods with default service account access and one granting secret-reading permissions?