Third-party access needs technical boundaries, not just contracts

A supplier needing remote access to support one business system does not automatically need a permanent trust relationship with the rest of the environment.

External access arrangements often grow gradually. An account created for a short project remains active. A remote support tool authorised for one appliance is extended to other systems. A vendor VPN stays connected because the organisation is unsure what would stop working if it were removed.

Each decision may have been made for a legitimate reason. Together, they can leave suppliers with standing access that is broader than their present responsibilities.

A contract can define the support relationship. Only technical controls can determine what a supplier is actually able to reach, administer and change.

Remote support is part of the infrastructure architecture

Supplier agreements are important. They establish responsibilities, service expectations, permitted activities and, where relevant, notification and audit arrangements.

They do not by themselves enforce access to infrastructure.

The Australian Signals Directorate's (ASD) September 2026 Information Security Manual guidance on procurement and outsourcing makes this distinction explicit. Service-provider access should be subject to the normal protections for users, privileged accounts, remote access and administrative work.

New controls in that guidance also address the need for an organisation to explicitly approve the remote management tools, source network addresses and time windows available to its service providers.

In practical terms, a controlled support arrangement should establish:

• Identity: Who is connecting, and can the activity be attributed to an individual?
• Scope: Which specific systems and services can that person reach?
• Method: Which remote access or administration tools are approved?
• Origin: Where may the connection come from?
• Timing: When is access available, and how are emergency exceptions handled?
• Privilege: Which administrative rights are genuinely required for the assigned task?
• Revocation: How will access be removed when the work or relationship changes?

The purpose is not to make legitimate support difficult. It is to avoid turning a convenient support path into an unexamined, permanent administrative route through the organisation.

A supplier VPN is not a security boundary on its own

A VPN can protect the confidentiality of traffic between the supplier and the business. It does not automatically make the resulting access appropriately restricted.

For example, a vendor may need to administer a single application server. Giving that connection broad reach into the internal network is a different arrangement from allowing access only to the service and management interfaces required.

The same concern applies to remote desktop tools, jump hosts and centrally managed support agents. A support tool that can connect to many endpoints may be operationally convenient while also creating a powerful administrative pathway.

A well-designed approach limits access according to the work being performed. Depending on the environment, this may use individually attributable accounts, multi-factor authentication, least privilege, defined access paths and network controls that prevent unnecessary movement between systems.

These are complementary measures, not interchangeable ones. Multi-factor authentication does not compensate for unrestricted network reach, and a tightly filtered network path does not remove the need to manage privileged identities.

The organisation needs its own evidence

Supplier access is difficult to oversee if the service provider controls the only record of what happened.

ASD's September 2026 ISM includes a requirement for service-provider access to be independently logged by the organisation, in a way that the provider cannot modify or delete. The guidance also calls for timely analysis to detect unexpected, anomalous or unauthorised activity.

That is meaningfully different from asking a supplier to provide a log export after an incident.

Independent visibility helps establish when a connection occurred, which account or method was used and whether the activity aligned with the authorised support arrangement.

The organisation does not necessarily need to duplicate every logging product or record every interaction in the same way. The appropriate controls depend on the systems involved, the sensitivity of the work and the technical capabilities available.

But evidence of supplier activity should not disappear when the supplier's tools, accounts or relationship become unavailable.

Third-party privileges should have a lifecycle

Access is easier to govern when it has a defined purpose, owner and review point.

That means avoiding supplier accounts that remain enabled indefinitely simply because nobody is certain who created them or whether they are still needed.

A practical lifecycle includes access approval, implementation, ongoing review and revocation. Reviews should also take place when a supplier's scope changes, a supported system is replaced, key personnel change or a project finishes.

Temporary exceptions need particular care. An emergency support request can justify short-notice access, but the exception should not silently become the default configuration once the incident is over.

For organisations with several vendors and inherited systems, a periodic Infrastructure Review can help identify remote support paths, persistent administrative permissions and dependencies that may not be evident from contract or asset registers alone.

A useful access register should describe not just who the supplier is, but how the technical access is provided, who owns it and how the organisation can disable it when necessary.

Supplier access is also a continuity dependency

An external provider can be operationally critical even when it does not host any business data.

The supplier might be the only party able to change a firewall, recover a storage platform, renew a certificate or administer a specialist application.

If an important service can only be repaired through one provider-controlled account or remote platform, that arrangement belongs in the service's dependency and recovery planning.

Organisations should consider what happens when a vendor is unavailable, a supplier account must be disabled during an incident, an administrative platform fails or the support relationship ends.

A secure design should retain appropriate customer control and a workable transition or recovery path without unnecessarily weakening the access restrictions during normal operations.

For regulated entities, the principle has a formal dimension. APRA Prudential Standard CPS 230 requires APRA-regulated organisations to manage material service-provider risks and maintain oversight of their arrangements. Those obligations do not apply to every Australian business, but the broader lesson is relevant: reliance on a supplier does not remove the customer's responsibility for its own operational risk.

Eight questions to ask about existing supplier access

A useful supplier-access review should be able to answer these questions:

1. Which providers can currently administer business systems? Include remote access tools, VPNs, management portals and support agents.
2. Can access be attributed to named individuals? Identify shared accounts or credentials that make actions difficult to trace.
3. Is access proportionate to the assigned work? Check administrative privileges and downstream network reach.
4. Are the connection methods explicitly approved? Review remote tools, entry points and controls on source locations or networks.
5. Can access be restricted by time or request? Determine when standing access is justified and when a defined support window is safer.
6. Does the organisation retain independent records? Establish whether supplier activity can be reconstructed without relying exclusively on provider-held logs.
7. Can access be withdrawn quickly? Confirm who can disable the connection, including outside business hours.
8. What happens if the supplier relationship or platform ends? Verify that essential administration and recovery remain possible.

These are not questions about choosing one particular remote support product. They establish whether the organisation still understands and controls the technical access being granted.

Keep supplier support efficient without surrendering control

The strongest third-party access arrangements combine commercial governance with technical enforcement.

The agreement sets out the work a supplier is authorised to perform. Identity, network and remote access controls limit what the supplier can reach. Monitoring creates independently accessible evidence of activity. Review processes remove access that no longer has a legitimate purpose.

Where existing arrangements require redesign, Infrastructure Design & Delivery can support clearer administration paths, identity controls, segmented access and controlled handover.

For organisations seeking recurring infrastructure support, Managed IT Services should also be evaluated in terms of access ownership, visibility and clearly documented responsibilities, rather than response times alone.

External expertise can remain useful and responsive without becoming an invisible source of standing privilege.

The contract describes the relationship. The infrastructure must enforce its boundaries.