When machine approval requirements are disabled, new devices no longer need administrator approval before joining the network. That lowers the barrier to access and can expand the blast radius of a compromised account or an unauthorized device. Teams should treat this as a control weakening event, confirm whether the change was intentional, and review whether existing access paths remain appropriate.
What device approval does in a Tailscale tenant
device approval is a tenant-side admission control. It adds an administrator review step before a new device becomes part of the network, which helps separate legitimate enrollment from silent expansion. When that control exists, the tenant is not just trusting authentication, it is also making an explicit trust decision about whether the device should be allowed onto the mesh.
Removing approval does not change the fact that the device must still authenticate, but it does remove a meaningful policy checkpoint. In practice, that means device onboarding becomes faster and less frictional, while the tenant also loses one layer of assurance that the joining device was expected, owned, or reviewed before it received network reachability.
For device governance, the important question is not whether the control was convenient, but whether it was acting as a backstop for enrollment risk. If your environment uses approval to contain unmanaged endpoints, contractor devices, or compromised user sessions, disabling it can materially alter the trust boundary even if the rest of the access model stays unchanged.
Why removing approval increases exposure
Once approval is removed, any identity that can complete the normal enrollment flow can usually bring a new device into the tenant without waiting for admin action. That makes the control more permissive by design, and the impact is greatest where account compromise, shared credentials, or weak endpoint hygiene already exist. The main exposure is not just more devices, it is more trusted devices sooner.
This matters because a newly admitted device may inherit the same network visibility and access paths as any other enrolled endpoint. If the enrolling account is compromised, the attacker does not need to wait for a second gate. If the device itself is untrusted, the tenant may have no practical opportunity to inspect it before it joins. For that reason, the change can widen the blast radius of both account takeover and unauthorized device use.
The risk is often underestimated when teams focus only on join speed. Approval is a small control with outsized governance value: it lets the operator stop unexpected growth, question anomalous enrollment, and prevent silent expansion after credential compromise. Removing it shifts more of that burden onto upstream identity assurance and downstream monitoring.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | CIS 5 — Account Management | Device approval removal changes how new devices/accounts are admitted to the tenant. |
| CIS 6 — Access Control Management | Approval is an access gate that constrains who can join the network and reach resources. | |
| Recommendation — Review account and device admission paths before allowing enrollment without approval. Enforce explicit access approval or equivalent gating for new devices and endpoints. | ||
| NIST CSF 2.0 | PR.AC-1 — Identities and credentials are issued, managed, verified, revoked, and audited | Removing approval weakens the verification step in device admission. |
| PR.AC-4 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Approval removal expands who can become authorized on the network. | |
| DE.CM-8 — Continuous monitoring of technology assets and their security configurations is performed | If approval is removed, monitoring must catch unexpected device joins and control drift. | |
| Recommendation — Keep device admission tied to verified identity and auditable revocation. Apply least-privilege admission rules before a device is granted network access. Monitor for unauthorized device enrollment and configuration changes continuously. | ||
Practitioner Guidance
What to verify: Confirm whether approval was disabled intentionally, and if so, document the business reason and the compensating controls that now carry the risk. If the tenant covers production systems or sensitive data, verify that you still have a reliable way to detect unexpected device enrollment and revoke access quickly.
Common mistake: Treating approval as an optional admin convenience rather than a control that helps bound trust. If you remove it, do not assume the remaining sign-in flow is enough to protect the tenant from over-enrollment or from a compromised account registering additional devices.
Decision rule: If the tenant includes unmanaged, shared, contractor, or high-impact endpoints, keep approval or replace it with an equally strong admission review process. If you cannot name the replacement control, the removal is probably a net weakening, not a neutral configuration change.
Practitioner takeaway: The key judgment is whether faster enrollment is worth giving up an explicit admission checkpoint, because once that gate is gone, trust shifts from pre-approval to post-enrollment detection and response.
Related resources from NHI Mgmt Group
- What happens when attackers disable GitHub security controls such as MFA, SAML, or personal access token approval?
- What happens when privileged infrastructure access is not tied to stronger device and second-factor controls?
- What happens when authentication is weakened by missing device controls or poor role scoping?
- What happens when employees use personal devices and unmanaged apps without device and credential controls?
