Create and securely manage Guest users on Sophos Firewall

Guest users on Sophos Firewall are time-limited accounts for people who don’t have a regular user account. They are suitable for visitors, external technicians, or training participants who sign in through the Captive Portal and should receive only clearly limited internet access.

The secure quick path is:

1. Prepare a restrictive guest group with the required policies.
2. Under Authentication > Guest user settings, specify the prefix, group, password, and cleanup behavior.
3. Decide whether an administrator creates single or multiple accounts or whether self-registration with SMS is genuinely required.
4. Set validity to Immediately or After first login and hand over the credentials securely.
5. Test the Captive Portal, user rule, network separation, and one allowed as well as one blocked destination.
6. Disable or purge the account after expiry and check existing sessions and logs separately.

⚠️ A guest account is only an identity. It doesn’t separate a network or open a traffic path. Guests belong in a dedicated zone or VLAN and receive a narrow, logged firewall rule. Credentials, printouts, and SMS messages must be handled like passwords.

Distinguish Guest users, vouchers, and regular users

A Guest user is a temporary local user record. The firewall generates the username and password from the global guest user settings. After sign-in, it can associate traffic with this identity and apply the policies of the selected group.

Other access models solve different tasks:

• Regular local or external user: Suitable for recurring users with a permanent account, central user source, or MFA. Create and manage normal local users explains the model maintained directly on the firewall.
• Guest user: Suitable for a time-limited person with an individual account, its own validity, and optional usage controls.
• Hotspot voucher: A code for a wireless hotspot. Voucher validity, online time, data volume, and device count are managed in the hotspot model. The setup is covered in Sophos Firewall hotspot with vouchers or a password of the day.
• Clientless User: Associates a fixed IP address with a device without requiring a person to sign in. This workflow is covered in Set up Clientless Users on Sophos Firewall.

Guest users aren’t intended for remote access SSL VPN or IPsec remote access. The current SSL VPN policy doesn’t allow Guest users or Guest groups as Policy members. Use a regular user from an appropriate local or external user source for remote access. The full VPN configuration is covered in Set up SSL VPN remote access.

Plan the example and prerequisites

The following example uses a dedicated guest network and an account for a one-day visit:

• Zone: Guest
• Network: 10.30.40.0/24
• Portal name: login.example.com
• Guest group: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 is a private example network and must be replaced with the real guest network. login.example.com is a documentation name. Replace it with an FQDN that resolves from the guest network to the reachable firewall address and is covered by the portal certificate. The group receives only the policies that are genuinely intended for this guest access.

The following prerequisites must be met before accounts are created:

1. Guest network, DHCP, DNS, routing, and NAT work without a user rule.
2. Internal networks and management services are blocked from the guest zone.
3. The Captive Portal is reachable only from the intended zone.
4. A dedicated group combines Access Time, quotas, Traffic Shaping, and Sign-in Restriction.
5. An administrator account and an independent management path remain available during testing.
6. Credential issuance, expiry, revocation, and retention are defined operationally.

Specify global guest user settings

Before creating the first account, open:

Authentication > Guest user settings

These values act as a template for newly generated guest accounts. A template change should therefore be tested with a pilot account first.

Choose secure general settings

Under Guest user general settings, specify the following fields:

1. Username prefix: guest- in the example. A neutral prefix is preferable to company, site, or customer names that disclose unnecessary information.
2. Group: Select Guest_Internet. Guest users inherit the policies of this group.
3. Password length: 16 in the example. Sophos allows a maximum of 50 characters for the Captive Portal. Choose a length that is sufficiently strong and can be entered reliably through the intended issuance process.
4. Password complexity: Select the strongest option compatible with the issuance and sign-in process.
5. Disclaimer: State brief terms of use, responsibility, and a contact. Real credentials or internal technical details don’t belong in this text. Configure the login disclaimer and messages on Sophos Firewall explains the global management of admin, authentication, SMTP, and SMS texts.
6. Auto purge on expiry: Turn this on only if expired user records should be removed automatically and the required operational evidence is retained elsewhere.
7. Click Apply.

Auto purge on expiry removes guest user details after expiry, but it doesn’t affect logs. This distinction matters for privacy and troubleshooting: account cleanup and log retention are separate processes.

Manage user groups securely on Sophos Firewall explains how group policies, the Main Group, and user overrides interact. The Default Group shouldn’t be used casually for guests. A dedicated restrictive group makes effects and rollback easier to understand.

Enable self-registration only when it is genuinely needed

Self-registration can be enabled under Guest user registration settings. It is more complex than controlled issuance by an administrator or reception desk and requires a reliable SMS process:

• Enable guest users registration: Turn this on only if guests should register themselves.
• SMS gateway: Select the provider that was tested beforehand.
• Guest username: Either use the mobile number or generate the name from the Username prefix.
• User validity: Set the maximum validity for self-registered accounts.
• Default country code: Choose a value that matches the actual user population.
• CAPTCHA verification: Keep this enabled to make automated registrations more difficult.

The firewall supports HTTP- and HTTPS-based SMS gateways. We recommend HTTPS so credentials and provider parameters aren’t transmitted in clear text. The URL, HTTP method, mobile number format, request parameters, and response format must exactly match the documentation from the selected SMS provider. Example URLs from a guide must not be copied into production.

Test connection sends a test message to a mobile number. According to Sophos, this test can fail for a private SMS gateway with an internal IP address even when the actual workflow works. Don’t simply assume success in that case. Test the complete registration with a mobile device, provider log, and the actual SMS message.

If there is no SMS gateway, responsible owner, or clean protection for the registration page, self-registration remains disabled. A responsible person then creates accounts in a controlled manner.

Create single or multiple guest accounts

Create a single account with a name and email address

For a specific visitor, open Authentication > Guest users > Add single:

1. For Name, enter a value such as Visitor Zurich 2026-08-11. This is the record name, not the later username.
2. Enter the email address intended for the guest.
3. Set Validity period to the required period, 1 day in the example.
4. Choose Validity start deliberately.
5. Click Add to save or Add and print to save and print the credentials.

Immediately starts validity when the account is created. This fits when the credentials are handed over and used immediately. After first login starts the period at the first successful sign-in. This option is usually better for visitor accounts prepared in advance because validity doesn’t expire before arrival.

After creation, the list shows the generated username. Don’t confuse the record name with the username when handing over credentials.

Generate multiple accounts for an event

Under Authentication > Guest users > Add multiple, specify the number of users, validity period, and validity start. Add and print creates the accounts and the associated printouts.

Multiple accounts should only be created for a specific event. Count the printouts, store them securely, and hand them to a responsible person. Disable or purge unused and expired accounts. A large stock of unassigned credentials weakens the technical controls.

Check the group, policies, and sign-in limits

A newly created guest account initially inherits the group selected under Guest user settings. Under Authentication > Guest users > Edit, check the name, password, mobile number, email address, group, and individual policies.

User-specific policies take precedence over group policies. An override therefore only makes sense for a documented exception. For a consistent guest model, Access Time, Surfing Quota, Network Traffic, Traffic Shaping, and Sign-in Restriction normally remain grouped in Guest_Internet.

The example uses the following limits:

• Sign-in restriction: Limit it to the real guest network or the matching Node range if the sign-in model allows it.
• Simultaneous sign-ins: 1, unless one guest account is explicitly permitted for multiple devices.
• MAC binding: Usually disabled for changing guest devices. The firewall doesn’t bind remote-access VPN users using MAC addresses in any case.
• Quarantine digest: Enable only if the account actually uses Mail Protection and has a defined quarantine process.
• Remote access policies: Don’t plan these as VPN access for Guest users.

Account validity solves a different problem than time and usage policies:

• Validity period determines how long the guest account can be used.
• Access Time allows or blocks internet access during recurring time windows.
• Surfing Quota and Network Traffic Quota limit online time or data volume.
• A firewall rule determines which zones, destinations, and services are reachable at all.

Don’t treat these layers as substitutes for one another. A valid account must not reach an internal server unless the firewall rule explicitly allows it.

Connect the Captive Portal and traffic path

Guest users normally sign in through the Captive Portal. Device Access, DNS, HTTPS, the user rule, and the selected authentication method must all match. The portal itself doesn’t permit internet access.

Run a complete positive and negative test from the guest network:

1. The client receives an address, gateway, and DNS from the guest network.
2. https://login.example.com:8090 is reachable and shows the correct certificate.
3. A normal web request leads to the portal.
4. A valid guest account can sign in.
5. Current activities > Live users shows the username and source IP.
6. The allowed internet test matches the expected user rule and Firewall Rule ID.
7. An internal destination and a disallowed service remain blocked.
8. An expired, disabled, or deliberately mistyped account is rejected.

The complete rule, Device Access, and HTTPS workflow is covered in Set up and test the Sophos Firewall Captive Portal. The Sophos portals guide distinguishes the User Portal, VPN Portal, and Captive Portal.

Issue credentials and operate accounts

The following operational actions are available under Authentication > Guest users:

• Print: Issue credentials in a controlled manner.
• Resend credentials: Resend credentials through the configured SMS gateway.
• Change status: Set an account to active or inactive.
• Change password: Assign a new password after loss or suspected exposure.
• View usage: Check internet usage and quota status.
• Reset user accounting: Reset usage counters and restart the Network Traffic Quota.

Reset user accounting changes state. Document the account, current usage, time, and reason beforehand. Don’t use reset as the first troubleshooting step because it changes the evidence and can grant the guest more quota.

For offboarding, disable the account first and run a negative sign-in test. Then check active sessions under Current activities > Live users, unused printouts, SMS access, and possible user-specific overrides. Delete the record or let Auto purge on expiry remove it only when no dependency remains.

Troubleshoot systematically

The record name doesn’t work as a username

With Add single, Name is only the label for the user record. The actual username is generated from the Guest user settings and appears in the list or on the credential printout. Use exactly that value with the generated or changed password.

The account is valid immediately or not yet valid

Check Validity start and Validity period. With Immediately, time starts when the account is created; with After first login, it starts at the first successful sign-in. Also check the firewall time and time zone. A broader firewall rule doesn’t repair an expired account.

Self-registration doesn’t send an SMS message

Check whether Enable guest users registration is on, the correct SMS gateway is selected, and the mobile number, country code, URL, HTTP method, request parameters, and response format match the provider. Then check the provider log and actual SMS delivery.

A successful Test connection doesn’t prove the complete registration and Captive Portal workflow. Conversely, according to Sophos, a failed test against a private internal gateway doesn’t automatically prove that the SMS path is broken. Test with a real pilot account in both cases.

Sign-in works, but internet access doesn’t

Under Current activities > Live users, check whether the guest appears with the expected source IP. Then check the group, user-specific overrides, validity, Access Time, and quotas. In Log Viewer, the test traffic must match the expected user rule and Firewall Rule ID.

If the user is missing from Live users, inspect the sign-in path using access_server.log and the documented test time first. If the user is visible, the next check is the rule, routing, NAT, DNS, or protection policy. Troubleshoot authentication errors systematically separates these phases.

The guest account can’t be selected for SSL VPN

This is expected product behavior. Guest users and Guest groups aren’t valid Policy members for remote access SSL VPN or IPsec remote access. For an external technician who requires VPN, use a regular, narrowly authorized user with the appropriate MFA and remote access policy.

Operational checklist

• Guest network, zone, DNS, routing, and NAT were tested separately.
• Internal networks and management services remain blocked.
• A dedicated restrictive guest group is selected.
• Username prefix, password length, complexity, and Disclaimer are documented.
• Validity period and start match the issuance process.
• Self-registration is enabled only with a tested SMS and CAPTCHA workflow.
• Credentials are generated, handed over, and destroyed securely.
• The guest appears under Live users after sign-in.
• Positive and negative tests confirm the user rule and Firewall Rule ID.
• Access Time, quotas, and user overrides were reviewed deliberately.
• Expired accounts, sessions, and printouts are cleaned up in a controlled manner.
• Reset user accounting is used only with documented approval.

Frequently asked questions