ASD ISM 2124 Restricting service provider access to approved tools, addresses and time Windows
What it says
Access by a service provider to an organisation's systems is restricted to remote management tools, source network addresses and time windows explicitly approved by the organisation.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishService providers may only reach your systems through the remote management tools, source network addresses and time windows your organisation has explicitly approved in advance.
When an outsourced IT, managed service or software vendor needs to reach into your environment, that access is a standing doorway into your systems. This control says the organisation, not the provider, decides exactly how that doorway is shaped. Three things must be explicitly approved: the remote management tools the provider is allowed to use, the source network addresses (such as specific IP addresses or ranges) the connections may come from, and the time windows during which access is permitted. Anything outside those approved boundaries should not be possible. This matters because provider access is a favourite target for attackers. If a provider's staff credentials or remote tooling are compromised, an attacker inherits whatever the provider can reach. Limiting access to named tools stops a provider (or an attacker posing as one) from quietly installing their own remote access software. Limiting source addresses means a stolen credential used from an unknown location is refused. Limiting time windows means a connection at 3am on a Sunday, when nobody is expecting maintenance, is blocked rather than accepted, and unexpected attempts stand out as a warning sign. Together, these boundaries shrink the window of opportunity for misuse and make legitimate provider activity predictable and easy to distinguish from something hostile.
Free. Save your status, tasks and notes.
Why it matters
Without these restrictions, a service provider (or anyone who has compromised the provider's credentials, tooling or network) can connect to your systems from anywhere, at any time, using whatever remote access software they choose. A single compromised provider account then becomes an unrestricted, always-open path into your environment, and malicious activity blends in with legitimate support work because there is no approved baseline to compare it against. This raises the likelihood of undetected intrusion, data theft and disruption through the supply chain, and leaves the organisation unable to demonstrate that it actually governs third-party access.
How to implement
Have the contract or vendor manager, together with the security team, agree with each service provider a written list of the specific remote management tools they may use, the source network addresses their connections will originate from, and the time windows in which access is permitted, and record these in a provider access register signed off by an approver in the organisation.
Have network or firewall administrators configure the perimeter firewall, VPN concentrator or remote access gateway so that provider connections are accepted only from the approved source addresses, using explicit allow rules per provider and a default deny for everything else.
Have system administrators enforce the approved tool list by permitting only the approved remote management software through the gateway and on the target systems, and by blocking or removing any other remote access tools through application control or endpoint configuration.
Have network or identity administrators apply time-based restrictions, such as firewall rule schedules, remote access gateway access policies or account logon hours, so that provider connections outside the approved time windows are rejected automatically rather than relying on the provider to comply voluntarily.
Have the security team set up a change procedure and a regular review so that any request from a provider to add a tool, change a source address or extend a time window is explicitly approved by the organisation before the technical rules are updated, and so that stale approvals are removed when they are no longer required.
Keep it running
Day to day, this control lives in three places: the approval record, the technical enforcement, and the change process that keeps them aligned.
Keep a single register of every service provider with access, listing for each one the approved remote management tools, the approved source network addresses and the approved time windows. That register is the source of truth; firewall rules, VPN or remote access gateway policies and tool allow-lists should be derived from it, not the other way round.
Expect the approved values to change. Providers renew their internet connections and change their egress addresses, replace their remote management platforms, or ask for extended hours during a project. Treat each of these as a change request that must be explicitly approved by the organisation before the technical rules are updated. Emergency or out-of-hours access should follow the same approval path, even if it is expedited, so that a temporary window is recorded and later closed.
Review the register periodically (for example at contract renewal or on a fixed schedule) and remove approvals for providers, tools, addresses or windows that are no longer needed. Connection attempts from unapproved addresses, outside approved windows or using unapproved tools are worth alerting on, because they indicate either a provider drifting from agreed practice or an attempt to misuse provider access.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or record that lists, for each service provider, the approved remote management tools, approved source network addresses and approved access time windows.
Look at
Check that all three elements are recorded for every provider with system access and that each entry shows who in the organisation approved it and when.
Good evidence
Every provider with access has a complete, explicitly approved entry covering tools, addresses and time windows, with no providers accessing systems that are missing from the register.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the firewall, VPN or remote access gateway rules that govern inbound provider connections.
Look at
Compare the permitted source addresses in the rules against the addresses in the approval register and check that everything else is denied by default.
Good evidence
The technical rules match the register exactly, with per-provider allow rules from approved addresses only and no broad or any-source exceptions.
- Check 3 of 5What an auditor asks for
Ask for
Ask how the organisation ensures providers can only use the approved remote management tools.
Look at
Look at gateway configuration, application control policies or endpoint settings that allow the approved tools and block others, and check for evidence that unapproved remote access software is detected or prevented.
Good evidence
Only the tools named in the register are technically able to establish provider access, and there is evidence that other remote access tools are blocked on the systems concerned.
- Check 4 of 5What an auditor asks for
Ask for
Ask how approved time windows are enforced.
Look at
Look for scheduled firewall rules, gateway access policies or account logon-hour settings, and sample connection logs to confirm that attempts outside the window are rejected.
Good evidence
Time restrictions are enforced by configuration rather than by trust, and logs show no successful provider connections outside the approved windows.
- Check 5 of 5What an auditor asks for
Ask for
Ask for recent examples of a provider requesting a change to its tools, addresses or access hours, including any emergency or out-of-hours access.
Look at
Trace each example from the request through explicit organisational approval to the update of the technical rules, and check that temporary changes were later reversed.
Good evidence
Changes are approved by the organisation before rules are altered, the register and configuration are updated together, and temporary windows are closed once the work is complete.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-2124 requires that service provider access to an organisation's systems is limited to explicitly approved remote management tools, source network addresses and time windows. Annex A 5.15 requires the organisation to establish and implement rules and procedures to control logical (and physical) access based on business and security requirements, within which third-party remote access restrictions can be defined. ISM-2124 is a specific, prescriptive access-control rule for supplier remote access, whereas Annex A 5.15 is a broader policy/procedure control covering access control generally.
This control partially meets A.8.3.
ISM-2124 requires service providers to access systems only via approved remote management tools, approved source addresses, and approved time windows. Annex A 8.3 requires restricting access to information and associated assets in accordance with an access control policy, which can include conditions such as allowed connection methods, IP allow-listing, and scheduled access. ISM-2124 is a specific implementation pattern for third-party remote access, while Annex A 8.3 is broader and not limited to service providers or remote management contexts.
This control partially overlaps A.5.18.
ISM-2124 requires that service provider remote access is constrained to approved tools, source network addresses, and time windows. Annex A 5.18 focuses on provisioning, reviewing, modifying and removing access rights to information assets, which is the governance process used to authorise and maintain those supplier access constraints over time. ISM-2124 emphasises connection conditions (how/where/when access occurs), while Annex A 5.18 emphasises lifecycle management of the underlying entitlements.
This control supports A.5.21.
ISM-2124 requires that service provider access is tightly controlled through explicitly approved remote management tools, source addresses and time windows. Annex A 5.21 supports this by requiring defined processes to manage ICT supply chain information security risks, which commonly includes constraining and governing third-party remote administration channels. ISM-2124 is a specific technical/operational control for remote access, while Annex A 5.21 is broader supply-chain risk management across products and services.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.