Defguard combines WireGuard management, identity, multi-factor authentication, and device enrollment. The enrollment flow deserves separate attention from the VPN data path. An enrollment token is designed to let a new device obtain configuration and identity. If the token is exposed or the enrollment endpoint is too broadly reachable, a temporary onboarding credential can create a durable network member.

A ZoomEye count-only probe on 2026-11-11 at 22:43 UTC returned 0 for app="Defguard" and 546 for title="Defguard". The probe used page 1, page size 1, and sub_type="all" [1]. The title matches are product leads, not a guarantee that the visible host is the primary management server or that enrollment is enabled. The zero app count limits the conclusion that can be drawn from fingerprinting alone.

How the token is meant to work

Defguard documentation describes a secure remote enrollment process in which a user receives a token from an administrator. The token is valid for 24 hours from issuance and for 10 minutes from first use, according to the vendor FAQ [2]. Those two windows serve different purposes. The first limits how long an unused token can circulate. The second limits how long an enrollment session can continue after it starts.

The user may authenticate through internal Defguard SSO or an external provider. When external SSO is used, Defguard is responsible for the VPN and the VPN client is configured after the external login [3]. This creates a chain of trust across the identity provider, the enrollment service, and the device configuration. A failure at any point can create a device that the administrator did not intend.

Inventory and scope

Identify the admin UI, enrollment service, and public proxy separately. A public enrollment proxy may be required for users who cannot reach the internal network before they have a VPN configuration. That does not mean the admin UI or the database should be exposed on the same route. Confirm the hostname, certificate, and owner of every Defguard title match.

Review enrollment policy. Determine who can start enrollment, how tokens are delivered, whether device information is verified, and which network profile a device receives. Check whether a single token can enroll more than one device, and whether a device can reuse the configuration after its user's access changes. The vendor documentation should be consulted for the current settings and limits.

List MFA and SSO requirements for administrators and users. If external SSO is enabled, verify the group or attribute mapping that grants access. A user who is disabled in the identity provider should lose the ability to enroll or reconnect. Test that behavior with a controlled account rather than assuming that the next login will fail.

Token handling

Enrollment tokens should be delivered through a channel appropriate to their sensitivity. Do not put them in public chat, shared documentation, or a generic ticket field. Set a process for canceling a token before its expiry when a user no longer needs access. Log issuance and redemption with the administrator, user, device, and time. A token that is redeemed from an unexpected network should be investigated.

If an enrollment token is compromised, revoke the resulting device and any peer configuration it created. Changing the user's password is not enough if the device already holds a valid network key. Remove the peer from the VPN and review whether it accessed internal resources. Rotate any other tokens delivered through the same channel.

Detection

Monitor enrollment starts, token redemptions, failed redemptions, new devices, and changes to network profiles. Alert on a token being redeemed from more than one device or from a network that is not consistent with the user's normal location. Correlate enrollment events with identity-provider sign-ins and MFA changes. A token redemption without a corresponding approved user action is a high-signal event.

The 546 title matches can help identify candidate Defguard portals, but a title alone cannot show whether the enrollment proxy is exposed. Use the title list to find owners and compare it with the internal Defguard inventory. The 0 app result should remain in the report so readers do not mistake a title count for a validated product census.

Hardening checklist

Keep the admin UI behind an authenticated management path. Publish only the enrollment service that users actually need. Require MFA for administrators and verify the identity-provider mapping for ordinary users. Shorten token validity if the organization's onboarding process allows it. Log issuance and redemption, revoke unused tokens, and remove devices promptly when access changes.

Defguard's enrollment design is meant to make remote onboarding practical. The security value comes from treating the token as a short-lived credential with a clear owner and a visible redemption trail. A public title count is only the first step in finding those flows.

References

[1] ZoomEye count-only observation, https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkRlZmd1YXJkIg==

[2] Defguard FAQ and enrollment token limits, https://defguard.net/faq/

[3] Defguard enrollment documentation, https://docs.defguard.net/using-defguard-for-end-users/enrollment/with-internal-defguard-sso

[4] Defguard overview, https://docs.defguard.net/features/overview