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. Set up SSL VPN remote access describes how to configure regular VPN access.

The current SFOS 23 help page Edit guest user still lists SSL VPN and IPsec remote access fields. However, the SFOS 23 help pages for SSL VPN policies and IPsec settings explicitly exclude Guest users and Guest groups from these two remote access methods. This is an unresolved documentation contradiction within the same version, not a verified version change. The fields aren’t evidence of supported guest VPN access; use a regular user for SSL VPN and IPsec. These exclusions don’t establish guest eligibility for Clientless SSL VPN, L2TP, or PPTP; those parts of the Edit page remain unresolved.

The same contradiction exists in the SFOS 22 help pages. The Edit pages in both versions also describe browser bookmarks for Clientless SSL VPN policy and optional assigned IP addresses for IPsec remote access, L2TP, and PPTP. These field descriptions aren’t authorization to enable these methods for guests. Don’t add remote access permissions for the internet access described here. Meet a separate VPN requirement with a regular user and the appropriate VPN runbook; don’t enable the unresolved guest options experimentally in production.

Example configuration 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 have been tested with a narrowly scoped temporary test rule. Remove this rule before testing authentication; a separate DNS rule may allow only the required resolver traffic.
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 each for the username and password on 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: This text is printed below the generated credentials. State brief terms of use, responsibility, and a contact. Real credentials or internal technical details don’t belong in it. 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.

For API automation: The SFOS 22 and 23 API documentation limits UserNamePrefix to 10 characters; guest- fits within this limit. This is a documented API constraint, not evidence of validation in every GUI version. The password length recommendation remains 16. Read the current settings before making a change and use a single pilot account to check the actual generated credentials, group, and validity.

The API examples aren’t fully consistent: PasswordComplexity uses symbolic values in the example but an integer definition in the attribute table; AutoPurgeOnExpiry shows Enable/Disable in the example but only Enable in the table. Don’t guess these values. Establish the supported schema for the actual appliance version before an API write; otherwise use the documented GUI fields. API defaults and digit-count constraints don’t establish universal GUI defaults or validity limits.

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 in days.
• Default country code: Choose a value that matches the actual user population. This default is displayed with the mobile number field on the guest registration page.
• CAPTCHA verification: Keep this enabled to make automated registrations more difficult.
• Click Apply.

The firewall supports HTTP- and HTTPS-based SMS gateways. HTTPS is preferable 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.

Map the SMS gateway parameters correctly

Under Authentication > Guest user settings > SMS gateway > Add, enter Name, URL, HTTP method with Get or Post, Cell number format, and, where applicable, Use country code with mobile phone number and Number prefix. The GUI help describes Number prefix as accepting alphanumeric and ASCII special characters. This isn’t a blanket promise for the API: its CellNumberPreFix field explicitly excludes commas.

Each request parameter has a Name and Value; SFOS replaces {mobileno} and {msg} with the mobile number and message. For the response, map Parameter index and Name to the Response format. Parameter names aren’t defined by SFOS and must exactly match the provider. This pattern uses reserved example values only:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

Replace sms.example.net, mobile, message, and status with the real SMS provider’s values. Get requests the specified resource; Post submits data for processing. Choose the method required by the provider’s API, not a general preference. Special characters in provider-required URL values must be percent-encoded, for example @ as %40. Credentials in the URL or request are secrets and don’t belong in screenshots, tickets, or logs. If the provider requires them, use HTTPS only and document their expiry.

Response format only describes how to parse the response. In the documentation example, a response such as status=302&message=Limit Exceeded indicates that a limit has been exceeded, not successful SMS delivery. Check the success or error status against the provider’s documentation and verify actual receipt. Save the gateway with Save first, then run Test connection with a mobile number you control.

API constraints and duplicate parameters: For SFOS 22 and 23, the API documents a maximum of 100 characters and no comma for gateway Name, and a maximum of 255 characters for ResponseFormat. Apply these limits to API requests; confirm the WebAdmin limits separately. Duplicate ParameterName and ParameterValue entries in the request and response lists aren’t ignored. Check every name/value pair for accidental duplication; retain intentional repetitions only when required by the provider. This doesn’t establish how a provider interprets them or mean that multiple SMS messages are automatically sent. The API URL table also lists FTP and IPv4 addresses, whereas the GUI help describes HTTP/HTTPS. This doesn’t extend this guide to FTP or unencrypted transport: use HTTPS only for secrets. An API operation status of 200 doesn’t replace actual SMS receipt or a complete registration test. Use a controlled test number with consent; provider charges may apply.

Under Administration > Messages > SMS customization, click Edit, enter a message that matches the template accepted by the provider, and save it with Apply. The placeholders {username}, {password}, and {expirydate} are available there for the message text. This saves the message separately. A mismatched template can cause the provider to reject the message and Test connection to fail.

The provider test is only a partial check: In the pilot, a guest connects to the guest Wi-Fi, opens Register for internet access, fills out the form, completes the CAPTCHA, and saves with Save. Successful registration displays the sign-in page. The SMS actually received must contain the username and password; the guest then signs in with these credentials. The record must then be visible under Authentication > Guest users and the sign-in under Current activities > Live users. Traffic must be logged with the expected user and Firewall Rule ID. A broad Any rule isn’t a substitute for this evidence.

If there is no SMS gateway, responsible owner, or adequate protection for the registration page, self-registration remains disabled. A responsible person then creates the 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 responsible email address. This field doesn’t send the credentials; Sophos documents Add and print or SMS for that purpose.
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. Use this value, not the record name, when handing over the credentials.

Generate multiple accounts for an event

Under Authentication > Guest users > Add multiple, specify Number of users, Validity period, and Validity start. Add creates the accounts without printing. Add and print creates the accounts and the associated printouts.

When creating accounts through the API: SFOS 22 and 23 document a range of 1–100 for NoOfUsers per request. This isn’t a verified maximum for Add multiple in the GUI. Split larger issuance runs into deliberately sized API batches. Record the intended count, global template, and validity start beforehand, and check a single account first. After each request, reconcile the usernames actually created and the printouts; if the response is uncertain, read the account list before blindly repeating the creation request. The API example omits NoOfUsers even though the table marks it mandatory, and doesn’t explain the 1/2/3 values for Expirty Period type. Don’t derive a complete request or expiry-value mapping from it; establish the version-specific schema first. Don’t reinterpret Name as Username; issue the generated credentials in a controlled manner.

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, then save with Save.

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. Traffic shaping associates the user with a QoS policy. This can define policy association, priority, and separate upload and download limits.

The example uses the following limits:

• Sign-in restriction: User group nodes inherits the guest group’s restriction. For an individual exception, limit Selected nodes or Node range to the sources actually required. Any node only fits when sign-ins from every network are intentional and protected separately.
• Simultaneous sign-ins: 1, unless one guest account is explicitly permitted for multiple devices. This limits the number of concurrent sessions; you can inherit the global value or specify an individual value.
• MAC binding: Usually disabled for temporary guests. The firewall doesn’t bind remote-access VPN users by MAC address in any case. When enabled, sign-ins are allowed only from the specified devices; enter their MAC addresses in MAC address list.
• Quarantine digest: Enable only if the account actually uses Mail Protection and has a defined quarantine process. The digest sends the list of held emails to the user’s inbox.
• 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.

Account validity, time limits, and usage limits don’t replace a restrictive firewall rule. A valid account must not reach an internal server unless the 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.

Configure DNS and the user rule separately

Under Rules and policies > Firewall rules, select the appropriate IP protocol and Add firewall rule > New firewall rule. The SMS example uses two rules from WiFi to WAN: one for DNS, the other for user traffic with Any. Narrow these broad example values for the real guest network:

1. Set the DNS rule to Action: Accept, Source zones: Guest, and the network 10.30.40.0/24 under Source networks and devices. Under Destination networks, select only the intended resolvers, and under Services, select only DNS. Destination zones must match the resolvers’ actual location; WAN is correct only for external resolvers. Don’t require a prior user sign-in for this essential name resolution.
2. Also set the user rule to Action: Accept, the same guest zone and source network, Destination zones: WAN, and only the intended internet destinations and services. Enable Match known users, select Guest_Internet under Users or groups, and enable Use web authentication for unknown users. The SFOS 22 and 23 SMS help pages still call this last option Show captive portal to unknown users; the current firewall rule pages in both versions use Use web authentication for unknown users. The different labels aren’t evidence of different behavior.
3. Enable Log firewall traffic and save each rule with Save. Check their position so that an earlier broad allow rule can’t bypass the user check and existing blocks on internal networks and management services remain effective. Continue to check NAT and portal access separately. Before sign-in, a connection must not have unrestricted internet access beyond the explicitly required pre-authentication services.

Guest and 10.30.40.0/24 represent the prepared zone and its real network. Choose resolvers, internet destinations, and services according to the guest access requirements, rather than setting them all to Any. If the firewall itself is the DNS resolver, this is a local service: allow DNS access under Administration > Device access only from the guest zone instead of copying a WAN DNS rule.

Verify sign-in and restrictions

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.

On a dual-stack guest network, test this workflow separately for IPv4 and IPv6 because SFOS handles web authentication for IPv4 and IPv6 destinations separately. Also configure and test when the session ends under Authentication > Web authentication > Sign out user. Never isn’t appropriate for time-limited guest access.

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: Select the intended users in the list and issue their 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. Under Current activities > Live users, select its active session and terminate it with Disconnect; then verify that the user can’t sign in again and that the data path remains blocked. Next, check 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.

Retire an SMS gateway safely: Record the exact existing profile name, the selection under Guest user registration settings, and any need for Resend credentials beforehand. Document the configuration without secrets and store required secrets separately and securely so manual recreation can be prepared; this doesn’t make deletion reversible. While registration or credential resending is still required, select a replacement first and verify SMS receipt, complete registration, sign-in, and resending with a controlled pilot account. If self-registration is being discontinued, disable it before removing the profile; that alone doesn’t resolve any obligation to resend credentials. Leave the old profile intact if a required SMS path can’t be verified.

An authorized API deletion requires the old profile’s exact Name; don’t send an unscoped deletion. The documented operation doesn’t establish a particular GUI delete button or automatic dependency checks. After the change, read the profile list and gateway selection again and check the registration and sending paths that are still needed.

Document global settings, the SMS gateway, group, and rule before the pilot. For rollback, reset the individual changed values; alternatively, disable self-registration and the pilot rule. A full backup restore isn’t a quick undo step: It replaces the current configuration and restarts the firewall; in HA, restoring the Primary also causes an interruption. Reserve it for the documented emergency procedure.

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.

Final check

• The guest can reach only the intended destinations; internal networks and management services remain blocked.
• Validity, Access Time, quotas, and overrides match the credential issuance process.
• Self-registration remains disabled until the SMS and CAPTCHA pilot has passed.
• Live users, the rule ID, and positive and negative tests confirm the expected assignment.
• Offboarding disconnects active sessions and removes credentials and printouts that are no longer needed.
• Reset user accounting is performed only for a documented reason.

Frequently asked questions