Set up Sophos Firewall Access Time for users

An Access Time policy limits internet access for a user, group, or guest users to defined times. The policy combines a recurring schedule with Allow or Deny. However, it only applies to an identity that the firewall has actually recognized and to which the policy is assigned directly or through its main group.

The quick path for allowing internet access during office hours is:

1. Under Administration > Time, check the firewall time and time zone.
2. Under Profiles > Schedule, create a recurring schedule, such as Internet_OfficeHours.
3. Under Profiles > Access time > Add, create the Employees_OfficeHours_Allow policy with Action: Allow.
4. Under Authentication > Groups, assign the policy to a small pilot group.
5. Under Current activities > Live users, check the user and source address, and under Authentication > Users, check the expected main group.
6. Test a new internet connection both inside and outside the time window.
7. Only add further users after the positive and negative tests succeed.

⚠️ According to Sophos, changes to an Access Time policy take effect immediately. A shared policy should therefore not be edited spontaneously. First record the affected users and groups, document a pilot account and the previous state, and then test the time boundaries in a controlled way.

What Access Time actually controls

Access Time decides whether an authenticated user receives internet access at a specific time. The policy does not create a firewall rule or web policy, and it does not authenticate a user. The network path, user identification, rule match, and protection features must therefore already work.

Four elements are required for evaluation:

• a recurring Schedule containing days and times;
• an Access Time policy with Allow or Deny;
• an assignment to a user, group, or guest user;
• a recognized identity, for example through Captive Portal, STAS, SATC, or another suitable authentication method.

Choose Allow or Deny deliberately

• Allow: Internet access is allowed during the selected schedule and denied outside that window. This model fits employees, classrooms, or contractor accounts with clearly defined usage times.
• Deny: Internet access is denied during the schedule and allowed outside it. This model fits a specific block period, such as a recurring lesson or quiet period.

For new restricted access, Allow is usually easier to understand: the permitted window is directly visible in the object and can be tested positively and negatively with a small pilot group. Deny makes sense when the normal state must explicitly remain open and only a precisely defined block window is required.

Schedule, quota, and login time are different layers

Features with similar names solve different tasks:

• A Schedule only contains days and times. It gains an effect only through a firewall rule, policy, or Access Time policy. Sophos Firewall schedules for rules and policies explains the complete setup.
• Surfing quota limits the amount of internet time a user can consume. It is a usage allowance, not a fixed clock-time window.
• Network traffic quota limits the amount of data transferred.
• The validity of a guest account determines how long the credentials exist. It does not replace recurring Access Time.
• Clientless Users do not support an Access Time policy. If a fixed device should communicate only at specific times, the schedule is applied to a narrowly scoped firewall rule. Set up Sophos Firewall Clientless Users explains the IP-based identity.
• Schedule for device access in the administrator settings limits WebAdmin sign-ins. Regular Access time is not intended for that purpose.

Surfing quota and network traffic quota on Sophos Firewall explains how to create and assign both consumption allowances, review them under View usage, and reset them safely.

Several time layers should only be combined with documented intent. A firewall rule schedule can close the entire network path, while Access Time only affects the assigned users. If the two layers use different time windows, each boundary must be tested separately.

Plan the example and prerequisites

The following example allows an employee group internet access from Monday to Friday between 07:30 and 18:00:

• Schedule: Internet_OfficeHours
• Access Time policy: Employees_OfficeHours_Allow
• Action: Allow
• Group: Internet_OfficeHours
• Test user: access-time-pilot
• Time zone: Europe/Zurich
• Time window: Monday to Friday, 07:30 to 18:00

Names and times are sample values. In the real environment, take the group name, owner, time zone, and approved operating hours from the actual access requirement. A group should only contain users with the same time model.

Check these prerequisites before making the change:

1. Under Administration > Time, Current time and Time zone are correct. Configure Sophos Firewall system time and NTP explains the NTP configuration.
2. The pilot user can authenticate with the intended method.
3. Under Current activities > Live users, the username and source address appear; under Authentication > Users, the Group field is correct.
4. A suitable user or network rule allows the intended internet path and logs the test traffic.
5. The previous Access Time assignment, main group, and any user overrides are documented.

If the user cannot be identified as a live user, correct authentication first. An Access Time policy cannot reliably control an unknown identity by user or group.

Create the schedule and Access Time policy

Prepare a recurring schedule

Access Time policies only accept recurring schedules. A One-time schedule is not available here.

For the example:

1. Open Profiles > Schedule > Add.
2. Set Name to Internet_OfficeHours.
3. Set Recurrence type to Recurring.
4. Select Monday through Friday.
5. Set Start time to 07:30 and Stop time to 18:00.
6. Document the purpose, time zone, and owner in Description.
7. Click Save.

The schedule alone does not change any access. It is a reusable time object and can also be used elsewhere. Always check all usages before changing it later.

Create the Access Time policy

Next, connect the time object to the access action:

1. Open Profiles > Access time.
2. Select Add.
3. Set Name to Employees_OfficeHours_Allow.
4. For Description, enter, for example, Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Set Action to Allow.
6. Under Schedule, select Internet_OfficeHours.
7. Click Save.

This policy also has no effect until it is assigned to a user, group, or guest user.

Assign the policy to a group or user

Use a group as the normal operating model

For users with the same time model, a group is clearer than many individual assignments:

1. Open Authentication > Groups.
2. Create the Internet_OfficeHours pilot group or edit a suitably scoped existing group.
3. In the policy section, select Employees_OfficeHours_Allow for Access time.
4. Do not change other quota, traffic shaping, or remote access settings incidentally.
5. Save the changes.
6. Authenticate one test user in this group and check the actual main group.

Manage Sophos Firewall user groups safely explains how local and imported groups, the main group, and user overrides interact. The actual AD import remains in Connect Active Directory to Sophos Firewall.

Use a user override only deliberately

Under Authentication > Users, a separate Access time policy can be selected for an individual user. This user value takes precedence over the group policy.

An override is useful for a documented exception, but it can make group changes appear ineffective. If a group is configured correctly but one user behaves differently, check that user’s object first. To return to the group policy, do not select an arbitrary new individual policy. Restore the previous inherited state in a controlled way.

Only the main group counts for Active Directory

For AD users, Access Time does not evaluate Other group memberships. The main group shown under Group in the user object applies, unless a policy is explicitly selected for the user.

The order under Authentication > Groups > Reorder affects which imported group becomes the main group. Changing this order can therefore affect not only Access Time but also other features. Do not use it as a quick fix for a single user. A deliberately planned group order or a documented user exception is safer.

Changes to AD groups, group order, and their policies are applied the next time the user signs in. For a clean test, create a new authentication session and then check the main group again.

Control guest users through their group

Guest users on Sophos Firewall receive a group under Authentication > Guest user settings and inherit its policies. To apply a recurring internet time window to guests, assign the Access Time policy to this clearly scoped guest group.

The guest account’s Validity period remains an additional boundary: it determines how long the account is valid. Access Time determines the recurring allowed or denied times within that validity. Set up and test Sophos Firewall Captive Portal explains the guest sign-in and firewall rule.

Test the time boundaries reliably

A saved policy is not yet proof of success. Acceptance testing checks identity, policy, and real internet access together:

1. Document firewall time, time zone, schedule, and action.
2. Authenticate the pilot user again.
3. Under Current activities > Live users, check the username and source address; under Authentication > Users, check the main group.
4. Inside the Allow window, open a new HTTP or HTTPS connection to an allowed test destination.
5. In Log Viewer, check the user, group, source, destination, Firewall Rule ID, action, and timestamp.
6. Outside the window, test a new connection to the same destination and confirm the expected block.
7. For a Deny policy, perform the same test with the opposite expectation.
8. Only then assign additional users or the production group.

The firewall rule must still match the user, network, and destination. Test a Sophos Firewall rule properly explains how to evaluate the Rule ID, Log Viewer, and Packet Capture together.

Sophos documents that changes to Access Time policies take effect immediately. However, that does not amount to a general promise that every existing application session is terminated exactly at the time boundary. For security-critical requirements, observe a new connection and an already-running session separately.

Troubleshoot systematically

User has no internet access despite the policy

First check whether the current time is inside the schedule for Allow, or outside it for Deny. Then check the user identity and source address under Current activities > Live users, and the main group under Authentication > Users. If the user is missing from Live users, the next step is authentication, not a broader Access Time policy.

Next, check the firewall rule, user match, rule position, and Log Viewer. Access Time cannot repair a missing network path or a blocking web, application, or TLS policy.

Access works outside the Allow window

Check whether the expected user is actually being tested and whether a different Access Time policy is set in the user object. For AD, also check the main group and group order. An unauthenticated or incorrectly assigned test does not disprove the policy.

Then create a new test flow. An existing session can behave differently from a new connection. If the traffic appears in Log Viewer without the expected user, resolve user identification first.

A group change does not affect one user

An explicit user policy takes precedence over the group policy. Under Authentication > Users, check the Access time field and, for AD, the main group. Access Time does not evaluate Other group memberships.

After changing AD groups, authenticate the user again. Only then can the current group order and policy assignment be assessed.

Captive Portal appears unexpectedly

Sophos lists restricted Access Time, incorrect credentials, and exhausted quotas as possible causes of NTLM or Captive Portal problems. Check Access Time, Surfing quota, Network traffic quota, and credentials separately. Do not hastily switch the policy to Allow or broaden the schedule while the actual cause remains unclear.

A change affects more users than expected

A shared Access Time policy affects all its assignments immediately after a change. First restore the previously documented action and schedule. Then inventory the affected groups and user overrides, and test the new requirement with a separate pilot policy.

Plan changes and rollback

Before every production change, document the policy name, action, schedule, affected groups, user overrides, main groups, firewall time, and test result. This keeps the rollback unambiguous.

A controlled rollback is:

1. Restore the previous Access Time assignment for the pilot user or pilot group.
2. For AD, authenticate the test user again.
3. Under Current activities > Live users, check the user and source address, and under Authentication > Users, check the main group.
4. Test a new connection both inside and outside the relevant window.
5. Check Log Viewer and the Firewall Rule ID used.
6. Remove the new policy and schedule only after no dependencies remain.
7. Update the ticket, owner, and test result.

In operation, shared policies should have an owner and a meaningful description. When working hours, holiday models, or group structures change, review time windows and assignments again instead of silently broadening the policy further and further.

Operations checklist

• Firewall time and time zone are correct.
• The schedule is recurring and documented.
• Allow or Deny matches the intended normal state.
• The Access Time policy is assigned to the correct group or user.
• User overrides have been checked.
• For AD, the main group is correct; Other group memberships are not assumed.
• The pilot user appears as a live user and their user object shows the expected main group.
• Positive and negative boundary tests were performed with new connections.
• Firewall rule, user, Rule ID, and logs agree.
• The previous state and rollback are documented.

Frequently asked questions