No. The default join model can preserve an attack path that was already risky on-prem and make it easier to exploit in a managed directory. Organisations should decide explicitly which identities may create machines, how those actions are logged, and which computer objects are allowed to delegate.
Why AWS Defaults Can Be Unsafe for Workstation Join Permissions
Workstation join permissions are not just an administrative convenience. They define which identities can create or join computers, which often becomes a durable foothold if the setting is left broad. In managed directories, the default is usually designed for ease of onboarding, not for limiting blast radius, so organisations should treat it as a control decision, not a convenience setting.
The security issue is not the act of joining a machine by itself, but the downstream authority that comes with computer objects. If too many identities can create or join workstations, an attacker who compromises one of those identities may be able to establish a new trusted endpoint, reuse that trust for lateral movement, or abuse any delegation attached to the object.
That is why join permissions should be aligned to explicit business roles and change control. The answer depends on whether the identity is human admin, automation, or a delegated provisioning path, because each one creates different ownership, logging, and revocation requirements. If those boundaries are not defined, the directory becomes permissive by default rather than intentional by design.
What Should Be Controlled Instead of Relying on the Default?
The first control question is who may create or join machines. Organisations should narrow this to the smallest set of approved identities and make the policy explicit for each directory or environment. If provisioning is delegated, the delegation should be bounded, time-limited where possible, and visible enough that security teams can tell which identity performed the join.
The second control question is what those newly created computer objects are allowed to do. A workstation join can carry implicit trust into authentication, policy application, or delegation relationships, so the computer object should not inherit broad authority without review. This is where least privilege matters most: the object should receive only the permissions needed for its lifecycle and operational role.
The third control question is how the organisation will detect misuse. Join events should be logged, reviewed, and correlated with asset inventory so that a machine that appears in the directory also appears in endpoint management and security monitoring. If there is no reconciliation between those views, the environment may technically be governed but practically unauditable.
How Join Permissions Become an Access Path
A permissive join model can become an access path because it turns directory trust into a reusable security boundary. Once a workstation exists, it may participate in authentication, policy assignment, group membership, or delegation chains that were never meant to be open-ended. The risk increases when the same credentials can be used across multiple provisioning workflows or when machine objects are left with more authority than they need.
This is especially important in cloud-hosted or managed directory environments, where defaults often aim to make onboarding simple. Ease of deployment does not mean safe privilege design. If a default allows uncontrolled workstation creation, the organisation may end up with hidden asset sprawl, weak ownership, and the kind of over-trust that makes later containment harder.
When reviewing this setting, think in terms of durable security impact rather than one-time admin convenience. A workstation join is not just a setup task, it is a trust event, and trust events should be deliberate, observable, and revocable.
Risk and Threat Considerations
Broad workstation join rights can create a low-friction path for persistence and lateral movement. If an attacker compromises an identity that can create or join computers, they may be able to introduce a trusted endpoint, blend into normal administration, and use that foothold to expand access through delegation or policy inheritance.
Failure mechanism: Excessive join permissions let a compromised or overbroad identity establish new computer objects or trusted endpoints without sufficient review, which can bypass the intended security boundary around workstation onboarding.
Impact: The result can be untracked asset creation, broader delegated authority than expected, and a stronger path to privilege escalation or lateral movement inside the directory and endpoint estate.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Join rights should be restricted to the smallest set of approved identities. |
| AU-2 — Event Logging | Join events need auditable records to detect unauthorized machine creation. | |
| AC-2 — Account Management | Who can create or join machines is an account governance decision. | |
| Recommendation — Limit workstation join permissions to the minimum identities needed for provisioning. Log workstation join events and review them against provisioning approvals. Define which accounts may join workstations and revoke unused provisioning rights. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Workstation join permissions are an access control decision over directory trust. |
| Recommendation — Set explicit access rules for workstation join operations and delegate them sparingly. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Permissive machine join rights can create excessive authority for non-human actors. |
| NHI-01 — Improper Offboarding | Joined computers and their authority must be revoked when no longer needed. | |
| NHI-08 — Environment Isolation | Join permissions affect whether trust boundaries between environments stay separated. | |
| Recommendation — Reduce overprivileged machine and provisioning identities before they can join systems. Remove stale workstation joins and revoke associated machine permissions promptly. Segregate join rights so one environment cannot create trusted machines in another. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Workstation join permissions are part of access control and identity governance. |
| Recommendation — Constrain join authority and verify each machine creation event is attributable. | ||
Practitioner Guidance
What to verify: Confirm which identities can join workstations, whether that set is role-based, and whether the directory records who performed each join. If the answer is “everyone in provisioning” or “the default”, the control is probably too broad for production use.
What good looks like: Join authority is limited to a named provisioning path, workstation objects are inventoried immediately after creation, and any delegated permissions attached to those objects are reviewed as part of onboarding rather than assumed safe.
Common mistake: Teams often harden workstation images but leave the join control untouched. That leaves an upstream trust path open even when the endpoint itself is well configured.
Practitioner takeaway: Treat workstation join permission as a privileged trust decision, not an administrative default, because the security outcome is determined by who can create the computer object and what that object can inherit afterward.