Gateway security guidance package: Gateway security principles

Introduction

Gateways play a vital role in securing networks by managing and controlling data flows between different security domains. As key boundary systems, they enforce security policies and help protect an organisations’ systems from external threats.

The Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) developed these principles as part of a broader suite of guidance designed to support organisations in making informed risk-based decisions throughout the lifecycle of their gateway systems, from design and procurement to operation, maintenance, and eventual decommission.

Key terms and concepts

Definition of a gateway

The definition of a gateway in the ASD's Information Security Manual (ISM): 

Gateways securely manages data flows between connected networks from different security domains

Gateways are a set of capabilities that enable an organisation to securely:

• provide services to external parties
• exchange information with others
• support remote work
• operate across trusted and untrusted networks (including the internet).

A gateway is a network boundary solution responsible for controlling data flow into and out of an organisation’s ICT environment or security domain. This position in the network means that gateways are critical implementation points. They provide a broad range of security capabilities that enforce an organisation’s security policies before allowing access into or out of the organisation’s network.

A gateway should:

• apply risk mitigations and cyber security controls to data flow between security domains
• provide visibility of transiting data according to an organisation’s policies.

All stakeholders involved in designing, procuring, operating, maintaining and disposing an organisation’s gateways need to understand the design principles and objectives of gateway controls.

Organisations can use gateway solutions through various delivery models, including on-premises, cloud-native, hybrid, or managed service provider (MSP) models. With cloud-native or MSP models, an organisation may use a gateway as an abstracted set of security services and capabilities rather than as specific equipment or functionality.

A gateway is typically comprised of a collection of physical, virtual and logical components that work together to provide the gateway’s core networking and security services. Factors that can influence an organisation’s gateway design include:

• the threat environment posed by connecting to external networks
• business and operational requirements, including regulatory obligations, service continuity requirements and strategies
• technical capabilities
• confidentiality, integrity, availability and privacy requirements
• threat modelling, risk appetite and risk management strategies
• integrations requirements between on-premises, cloud hybrid environments
• sourcing and service delivery models
• location and number of data centres, staff and office locations
• operational visibility and monitoring requirements.

Gateways must be designed to adapt to evolving threats, changing business needs, and emerging technologies, while providing consistent enforcement of security policies across all deployment models and environments. 

Cross Domain Solutions

Definition of a security domain

The ISM defines a security domain as:

A system or collection of systems operating under a consistent security policy that defines the classification, releasability and special handling caveats for data processed within the domain.

A security domain may be a collection of ICT services that have a degree of commonality, which is used to justify the collection being treated as a single homogeneous group when it comes to security. Therefore, as ICT footprints evolve, organisations must assess several policy factors when defining their security domains. Policy factors may include:

• purpose
• ownership or sovereignty (Australian or foreign owned or controlled)
• consistent implementation of administrative and security controls
• consistent security and operational visibility
• data value and sensitivity (security or otherwise)
• threats and risks to which they are exposed (risk profile)
• interdependency on other systems (e.g. data and application processing interfaces)
• data classification
• availability
• business impact level, information management markers and other caveats
• ability to perform cyber security incident response (e.g. manage a data spill)
• encryption.

Examples of different security domains include:

• an organisation’s OFFICIAL and PROTECTED networks
• PROTECTED networks of two different entities
• multiple government tenancies within a shared service provider, such as those hosted by MSPs or cloud service providers (CSPs).

This means that systems that are operated by different organisations, or systems that operate at different classifications, are in different security domains.

Most organisations will usually have at least two security domains (trusted/internal and untrusted/external). Security domains can span across data centres and segmentation models (such as those offered by CSPs), depending on risk tolerance and technical design. Note, as outlined in the Protective Security Policy Framework (PSPF), the security policy for a security domain includes:

• security governance
• personal security
• physical security
• information security.

When using cloud or managed services, an organisation should assess whether these services form part of an existing security domain or should be in a separate security domain. This should be informed by business and compliance requirements, risk appetite, enforcement capabilities and security guides for consumers and providers.

Security domains do not need to align with specific network topologies. For example, virtual private networks (VPNs) can unify multiple locations under a single domain as long as the VPN is isolated from the transport network by using appropriate controls.

Gateways play a critical role in protecting security domains. Organisations should design controls to reduce or eliminate the attack surface associated with data flow between domains. This includes using both traditional on-premises and modern security technologies such as:

• proxies and web application firewalls (WAFs)
• host-based firewalls
• software-defined networking (SDN)
• behavioural analytics
• API-based logic enforcements
• Security Service Edge (SSE) solutions.

Consumers and service providers may have different perspectives on how to define a security domain. Figure 1 shows that multiple customers may share a virtual environment managed by a third party. As each organisation (consumer) is responsible for protecting its own systems and data, it should determine its own security domains. However, where a service provider offers multi-tenancy gateway services, the service provider may retain administrative and policy control over the system. Therefore, in cases where there is no clear demarcation of where the security domain boundary exists, an organisation should consider treating these environments as separate security domains until satisfied that there is equivalent security policy enforcement and operational visibility.

• Monolithic: provides all gateway security functions through one centrally managed system (e.g. a secure internet gateway (SIG)). Capabilities such as firewalls, web filtering, intrusion prevent, and VPN concentrators are consolidated within one platform and control plane. This approach offers unified control, simplified management, and consistent policy enforcement across all traffic traversing the gateway.

• 

• Disaggregated: provides service-specific gateway functions through discrete but interoperable systems that do not share a common control plane but do share a common security policy. These services may be independently deployed and managed, but are typically coordinated through integrated or federated policy, identity, and telemetry frameworks, rather than operating in isolation. This approach enables flexibility, scalability, and the ability to adopt specialised capabilities. 

• Hybrid: Combines monolithic and disaggregated approaches, delivering gateway services across a mix of on-premises and cloud-based systems, often with multiple control planes and enforcement points.

 Regardless of the architectural approach, it is critical that gateway services and their cyber security capabilities evolve to support an organisation’s changing business requirements and risk management needs. Previous Australian Government gateway policies and frameworks applicable to non-corporate Commonwealth entities (NCEs)2 have historically advocated for the routing of internet traffic through a small number of well-controlled monolithic gateways, which provided all gateway security functions through one centrally managed system. These gateways quickly became the default place to concentrate cyber security capabilities as they controlled all traffic between a trusted internal network and the untrusted internet. However, this approach introduced constraints for system and network architecture, topology, and security controls. 

In contrast, disaggregated gateway architecture separates gateway functions across multiple systems and locations. Advances in service delivery models including cloud-native security services, and software-defined wide area network (SD-WAN) have highlighted that security controls no longer need to be enforced at a single network choke point.  

As a result, hybrid gateway architectures have emerged, combining centralised and distributed enforcement. These architectures enable organisations to apply security controls closer to users, devices, and application workloads, while retaining centralised governance and visibility. 

The continued evolution of gateway services and cloud-based service models is reshaping how organisations deploy and operate gateway capabilities. In many cases, traffic no longer traverses a single organisational gateway and may instead be inspected or controlled across multiple enforcement points. This introduce challenges where traffic is encrypted, distributed, or processed outside traditional visibility points, limiting the effectiveness of legacy security tooling.

Gateway architecture considerations example 

Table 1: gateway architecture consideration

Factor	Monolithic Gateway (SIG)	Disaggregated	Hybrid
Security control	Centralised and consistent	Distributed and context-aware	Balanced across environments
Integrated security visibility	High (single point of integration)	Fragmented unless integrated	Integration maturity dependent
Resilience	Lower (concentrated failure points)	Higher (distributed)	Moderate to high resilience
User experience	Often degraded (suboptimal network traffic flows)	Optimised for remote and cloud access	Mixed experience based on design
Cost model	Higher upfront infrastructure investment	Subscription and consumption based	Combination of both
Operational complexity	Easier to manage centrally	High due to multi-vendor integration	Very high due to mixed operating models
Implementation complexity	Low (well understood)	High (design and integration effort)	Very high (design and migration)
Zero Trust alignment	Limited	Strong alignment	Moderate to strong alignment
Scalability	Limited	Highly scalable	Very high
Strategic agility	Slow to adapt	Faster and more flexible	Moderate

Objectives of a gateway 

Without clearly understanding the capabilities or limitations of its gateways, an organisation cannot accurately understand and manage its operational or cyber security risks. Senior and executive decision-makers, as the accountable persons or authorities in their organisation, are responsible for ensuring all relevant stakeholders clearly understand their organisation’s gateway design principles and objectives. This includes ensuring alignment with risk appetite, business priorities, and assurance requirements. Gateway objectives should be expressed in terms of security outcomes, rather than specific technologies, to support flexibility across on-premises, cloud-native, hybrid, and managed service environments. These objectives underpin the effective application of modern defensible architecture approaches, and risk-based decision-making. 

An organisation’s gateway should achieve the following core cyber security objectives and functions: 

Visibility and telemetry 

Gateways should provide comprehensive visibility of data flows across all security domains. This includes generating, collecting, and forwarding security-relevant telemetry to support monitoring, analysis, and assurance activities. Effective visibility enables organisations to: 

• maintain situational awareness of network and application activity, including traffic that may not traverse traditional perimeter controls 

• support security operations, incident response, and forensic investigations 

• provide auditable evidence for governance, compliance, and assurance activities, including IRAP assessments 

• understand and observe data flows across users, devices, applications, and services. 

Detection and response 

Gateways should support the timely detection of anomalous behaviour, policy violations, and malicious activity. This requires continuous monitoring and analysis of data flows, authentication events, and system interactions. Detection capabilities should enable organisations to: 

• identify indicators of compromise, misuse, or unauthorised activities 

• correlate events across multiple control points, including distributed and cloud-based gateway services 

• initiate and support incident response activities to contain and remediate threats 

Detection and response capabilities should integrate with broader organisational security operations to ensure coordinated and effective handling of cyber security events. 

Prevention and policy enforcement 

Gateways should enforce organisational security policies to prevent unauthorised access, data exfiltration, and misuse of systems. This includes implementing controls that ensure only approved and validated data flows are permitted. Key outcomes include: 

• Enforcing cyber security policies and preventing data breaches through: 

• implementation of technical cyber security controls 

• authenticating, authorising and accounting (for specified services) 

• enforcing strong authentication, authorisation, and accounting, aligned with ASD’s foundations of modern defensible architecture 

• applying least-privilege access controls based on identity, device posture, and contextual risk 

• reducing the organisation’s attack surface by restricting access to only what is necessary 

• ensuring consistent policy enforcement across all gateway components and deployment models. 

Protection and resilience 

Gateways should support the protection and resilience of critical business services and data. This includes maintaining service availability, protecting sensitive information, and limiting the impact of security incidents. Gateways should: 

• support the secure delivery of essential services such as web hosting, email, and remote connectivity  

• implement compensating controls and mitigations for known vulnerabilities where immediate remediation is not possible. 

• limit or contain the impact of any compromise or incident through segmentation, isolation, and controlled data flows 

• maintain operational continuity through redundancy, failover, and fault-tolerant design. 

Policy enforcement point

A policy enforcement point (PEP) may be a hardware or software component, security device, integrated appliance, tool, function or application that enforces an organisation’s security policy on data flows, user actions, or system interactions.

Figure 5 below shows that PEPs may operate synchronously or asynchronously and can be implemented at various layers across different environments, including network and application layers. Together, they support a defence-in-depth approach to securing data flow across security domains. A PEP can be considered a core gateway capability responsible for enforcing security policy as data traverses between security domains. Often, multiple PEPs are deployed in sequence (chained) to meet the complete set of gateway enforcement requirements. This approach aligns with Zero Trust principles, where policy enforcement is applied at multiple levels, including network, application, and endpoint layers, rather than relying solely on a single perimeter control.

It is important to note that duplicating the same control in multiple locations does not inherently provide effective defence-in-depth. Each PEP should enforce a distinct and contextually appropriate policy, contributing to layered security outcomes. For example, a firewall or router enforcing network-level access control and an application proxy enforcing application-layer policies provide complementary controls. Simply replicating the same rule sets across multiple devices may increase complexity without improving security. PEP capabilities can be implemented across a range of components, including: 

• gateway services such as CDS, application proxies, and cloud0delivered security controls
• endpoint or workload level controls
• network infrastructure devices

Inadequate policy enforcement can expose entities to significant risks, including:

• unauthorised data access modification or exfiltration
• use of covert communication channels
• compromise of trusted systems or enforcement points, such as a firewall policy or edge device audit logs
• service disruptions, degradations, or denial-of-service
• lateral movement within internal security domains.

Organisations should design PEP implementations to support strong authentication and authorisation, comprehensive telemetry, and continuous validation of trust, consistent with Zero Trust and secure-by-design approaches. PEPs should also integrate with broader monitoring and assurance processes to support incident response, risk management, and compliance activities, including IRAP assessments. 

Note: the concept of a PEP has been adapted from the National Institute of Standards and Technology’s Special Publication 800-207, Zero Trust Architecture.

Gateway security principles

ASD’s ACSC has developed governance-related gateway security principles that an organisation should be aware of and consider when implementing or using a gateway. These principles should be applied when designing, procuring, operating, maintaining and disposing of a gateway.

Security management is continuous

Principle: Gateway security should be actively maintained, continuously improved and regularly reassessed to remain effective in a dynamic threat landscape.

Gateway security is not static. Tactics, techniques, mitigations, technologies and better practices evolve over time. Organisations need to continuously manage the security features and capabilities of gateway services to ensure optimal security outcomes, including timely deprecation of features that introduce operational risk. Gateways should form part of an organisation’s defence activities, through continuous monitoring and telemetry analysis to identify emerging threats, consumption of threat intelligence from trusted sources, and by integrating evolving better practices as identified in ISM updates and vendor advisories. Risk assessments for security domains should be periodically revisited and systems should be reviewed for fitness-for-purpose, and ongoing refinement of detection and prevention capabilities based on observed threats and incidents.

Risk is continuously managed

Principle: Gateway design and operation should be guided by risk-based decision-making, informed by threat modelling and aligned with the organisation’s broader risk management framework.

Organisations should conduct threat modelling to supports the identification of risks associated with gateway architectures, data flows, and dependencies. Using frameworks like MITRE ATT&CK helps organisations map gateway risks to specific adversarial behaviours, to controls and detection strategies, and to identify where ISM-aligned mitigations are needed. However, no framework is exhaustive. Each organisation must conduct its own risk analysis tailored to its systems, environment and tolerance. Design decisions must reflect obligations under the Public Governance, Performance and Accountability Act 2013 (PGPA Act) and be documented within the entity’s risk oversight structures. For more information on threat modelling, refer to ASD's Gateway security guidance package: Gateway operations and management.

Unseen traffic is unmanaged risk

Gateways protect organisations and staff

Principle: Gateways should prevent unauthorised information flows, protect users from malicious content, and enforce organisational policies using a default-deny approach.

A gateway should be positioned appropriately to inspect data flows with sufficient context to permit or block them based on defined policies. By default, all traffic should be denied unless explicitly allowed. Controls should help protect both systems and personnel by addressing the risks of insider threat, unintentional policy breaches and external attacks.

Plan for security flaws

Principle: Gateways should be designed to tolerate control failures and allow for rapid deployment of compensating measures to maintain resilience.

All systems, including gateways, are subject to vulnerabilities and potential compromise. Edge devices and user endpoints are inherently exposed and more likely to be targeted or compromised. Therefore, security design should focus on hardening and anomaly detection based on known adversary tradecrafts.

Compensating controls, including architectural measures, can limit the ability of a threat actor to maintain persistence and move laterally. All systems, including gateways, are susceptible to vulnerabilities. Defence-in-depth should be considered and applied to minimises adversary lateral movement and to ensure no single point of failure leads to an undetectable compromise.

Prior to implementing new systems, organisations should undertake table-top exercises in order to develop or update incident response capabilities, such as ASD’s cyber security incident response plans (CIRP), and test them. To the extent reasonably practicable, control design and placement should anticipate subversion of critical components noting that the organisation may have to plan for and respond to a number of techniques used by malicious actors. 

All systems are susceptible to bugs and security issues. Plans should be made in advance on how to deal with them. Pre-emptively building cyber resilience and response capabilities into systems can make it easier to deal with events as they arise. For example, monitoring for flaws and vulnerabilities introduced by vendors, being able to apply patches quickly, or disable a device known to be actively exploited.

Gateways can support resilience by restricting traffic or applying monitoring rules while remediation occurs, ensuring continuity during security events. For more information on resilient networks, refer to ASD's Foundations for modern defensible architecture.

Balance business and security

Principle: Gateways should enforce consistent security policies that also support diverse needs and operational contexts across security domains.

Security should be balanced with operational efficiency. Effective security balances business risk appetite and security policy objectives to empower business units to meet their operational objectives. Each security domain will have unique systems, security requirements and business objectives.

Environments such as development, sandboxing or research domains may require different levels of control. An organisation should demonstrate consistency in its approach to risk. Security policy exemptions, and inconsistent architectural and security capabilities in different systems will introduce risk to an organisation.

An organisation’s gateway should apply security policy consistently. An organisation should consider what additional governance and oversight mechanisms are needed where multiple gateways are deployed, or where security policies are enforced through different technology stacks.

Risk cannot be outsourced

Principle: An organisation owns its security risk, even if the organisation outsources or transfers, in full or in part, the implementation responsibilities.

The Department of Home Affairs’ Protective Security Guidance for Executives states that procuring goods and services does not transfer the operational risk from the Commonwealth. Security controls are intended to reduce an organisation’s risk, but an organisation cannot eliminate all risks. This means that the extent of the organisation’s security implementation responsibilities will vary depending on the type of deployment methodologies, services and contractual terms involved. Nevertheless, the organisation will always own the risk. An organisation inherits risk from dependent and underlying systems, including dependent services across multiple providers (e.g. MSPs, hyper-converged and multi-vendor cloud deployments).

Each organisation will have different responsibilities, threats, risks, legislative requirements, and obligations within its service delivery ecosystem. Actions should not be taken, whether contractual or otherwise, that prevent an organisation from meeting its responsibilities and obligations. All suppliers, service providers, and organisations have unique systems and responsibilities. This means an organisation must look at their risks by understanding the entire ecosystem in order to successfully use visibility, detection and prevention capabilities.

An organisation that enters into a contract that is not consistent with the ISM and the guidance provided in this document may be at risk of not fulfilling the requirements of the PSPF and the PGPA Act.

Placement of gateways

Organisations should view gateways as a suite of distributed security capabilities rather than a single, fixed network architecture. This approach provides greater flexibility in designing solutions tailored to specific environments while still maintaining a strong focus on risk reduction. Gateway placement should be driven by risk, data flows, and required security outcomes, rather than by legacy perimeter constructs. 

Gateways should remain the sole authorised mechanism for enforcing security policies and transferring information into and out of security domains. Depending on business and operational needs, an organisation may implement multiple gateways, such as for:

• internet connectivity
• cloud services
• data classification
• remote access for users and devices
• partner or supplier integrations.

Gateway designs should align with business requirements, particularly in terms of availability, confidentiality and integrity. Not all services require high availability, but critical business functions may demand greater resilience and throughput. In such cases, deploying a specialised or segmented gateway may be more effective than a single, centralised design.

All gateway related design decisions should be documented, including the rationale behind them. These decisions should:

• reflect the principles and controls outlined in this guidance
• capture the implementation architecture and associated risk treatments
• risk-informed, supported by threat modelling and aligned with organisational risk appetite
• be regularly reviewed by system owners and the authorising officer responsible for accepting residual risks.

Effective governance and oversight are critical, particularly in hybrid and multi-provider environments. Organisations should:

• clearly define roles and responsibilities across internal teams and external service providers
• ensure that procurement and contractual arrangements support required security outcomes, including visibility, control, and auditability
• leverage the expertise of enterprise architects, security practitioners, engineering and operations teams, and independent assessors to inform design and assurance activities.  

Cloud-based gateways

The following sections should be read in conjunction with the ASD’s Cloud assessment and authorisation and ASD’s Cloud assessment and authorisation FAQ. These publications provide an introduction to several key cloud concepts including the shared responsibility model and IRAP assessments of cloud-based gateway capabilities. The guidance is also potentially applicable to other outsourcing scenarios, including most MSP offerings.

Cloud-native capabilities

These capabilities can enhance both security posture and user experience.

Service-native integrations

Cloud-native gateways should use cloud-native services rather than retrofitting traditional, monolithic architectures. Service-native integrations enable security controls to operate within and alongside business applications, providing deeper visibility and more effective policy enforcement. They support improved security outcomes by enabling: 

• Continuous protection instead of point-in-time inspection. For example, a traditional gateway may only apply signature-based detection against payloads at the time data enters the security domain; however, a service-native integration could scan all the data stored within the service whenever a new signature is added.
• Integrated security context. Security controls can operate with richer contextual awareness, including user identity, device posture, data classification, and application behaviour. This enables more accurate and risk-informed policy decisions aligned with business objectives.
• Enhanced telemetry and auditability. Integration with cloud platforms enables detailed logging and monitoring of user and system activity, supporting detection, response, and assurance requirements, including IRAP assessments. 

Inter-organisation collaboration within a single cloud service provider

When two organisations (Enterprise A and Enterprise B) use the same underlying cloud service, and data flows occur between two different security domains (refer to Figure 6), then both organisation’s security policies must be enforced. This results in both organisations having visibility and control of data flows. It is therefore recommended that relevant application logs and context related to the specific data flows traversing both security domains are made continuously available to both participating organisations. Notably, both Enterprise A and Enterprise B could apply their own additional capabilities to the data flows through their respective PEPs. For example, additional message filtering or content conversion security capabilities via an API integration.

Figure 7 shows a similar example, but here the two consumer organisations (Enterprise A and Enterprise B) are relying on a shared common security domain, such as found in some Whole of Australian Government (WoAG) services. In this example, the WoAG providing organisation has decided to deploy an additional PEP that can enforce the security policy of all consumer organisations at the same time. It would be expected that the relevant information from the providing organisation is shared with the consumer organisations, and that the consumer organisations would have direct control over their own security policy.

Each consumer organisation is responsible for its own risk assessment and granting authorisation to operate (ATO) of the common service. In effect, it authorises each consumer organisation’s data to be transmitted, shared or processed by the shared service, while ensuring that the common service and PEP are in line with its own risk tolerances. For simplicity, additional PEPs within the consumer organisations have been omitted but these organisations can deploy them

Security zones

Security zones are logical groupings of systems, services, or workloads based on trust levels, sensitivity or functional roles. In gateway architectures, they help enforce separation between environments and enable the application of targeted security controls.

Gateways enforce these controls at the boundaries of each security zone, providing inspection, filtering and logging to manage and secure inter-zone data flows. Importantly, different security zones can have different security controls tailored to the risk and business context of the zone. This flexibility is particularly valuable in enabling specific scenarios while maintaining appropriate security postures. Figure 8 shows an example application.

• In security zone #1, the PEP applies all the appropriate protections to safeguard sensitive enterprise data held within zone #1.
• In security zone #2, the PEP provides logging capabilities but does not inspect or decrypt traffic (e.g. transport layer security between a virtual browser and the internet). This can be done, as there is no sensitive enterprise data within the lower security zone to protect.

This pattern is also applicable to sandbox, training or development environments where sensitive data is not present. However, data moving from a low security zone to a high security zone must be subject to strong security controls. For example, any code from the lower security zone would need to be treated as untrusted. Refer to the non-persistent virtualised sandboxed environment strategy from ASD’s Strategies to mitigate cyber security Incidents: Mitigation details. For more information on network segmentation, refer to ASD’s Implementing Network Segmentation and Segregation. 

Security Service Edge

• cloud access security brokers
• secure web gateways
• Firewall-as-a-Service
• Zero trust network access.

Secure Access Service Edge (SASE) builds on SSE by integrating cloud-delivered security services with network capabilities, such as software-defined wide area network (SD-WAN). Refer to Figure 9 below. 

Shared responsibility and trust

In providing cloud PEP solutions, there are shared responsibilities between the different parties managing all aspects of the cloud solution. For example, one party may be predominantly responsible for security capabilities but, then again, the various aspects of security capabilities may be shared between parties. In all cases, the cloud consumer must retain visibility across data flows and further secure data flows as they see fit. For example, filtering data flows containing files based on a YARA rule, or HTTP requests based on HTTP headers. Using MSPs and CSPs requires organisations to place some degree of trust in the service provider and take steps to ensure that an outsourced service provider is managing shared risks appropriately.

Gateway security is a shared responsibility between a gateway provider, the gateway consumer, and any other third parties who are involved in providing the complete gateway solution, including cloud platforms.

It is important to understand that PEPs can be effectively layered together across data flows. For example, one cloud service may use the security capabilities provided by another service offered from the same CSP, or the cloud consumer may deploy its own additional capabilities between the client and the cloud service resource. When layering PEP capabilities, it is important that they do not lower the security baseline provided by the CSP as this can introduce new weaknesses. The connection between the two security domains also needs to be secure. Furthermore, cloud consumers should also consider what else impacts a desired architecture when evaluating it, such as user experience or availability. Figure 10 outlines how a cloud-native PEP may need to be supplemented by a customer-deployed PEPs to appropriately enforce security domain separation.

Risk considerations for outsourcing gateway services

An organisation’s risk management process should consider and balance the benefits of an in-house gateway with the cyber security risks associated with outsourcing management of a gateway to a service provider. A risk assessment should consider whether the organisation, as a gateway consumer, is willing to trust its reputation, business continuity and data to a gateway service provider. Consideration should also be given to recovering the consumer’s data should it be insecurely transmitted, stored or processed.

The risks should be weighed against the security capabilities available in-house compared to an outsourced arrangement. In some cases, it may not be possible to independently verify whether a gateway provider is adhering to contractual terms, which leaves the consumer having to rely on third-party audits to find out. Consumers should consider which documents to request from a gateway service provider in order to assess risks and determine whether the contents of the documents provide the appropriate information to satisfy their assurance requirements or to identify gaps in their visibility.

Roles and responsibilities

Under the PGPA Act and the PSPF, an NCE’s Accountable Officer is the position responsible for understanding and managing risk within their organisation, and for granting systems an ATO. An organisation’s architecture, engineering and operations teams all play an important part in providing information that helps the organisation develop an understanding of its risk profile and the operating threat landscape. NCEs should review both the PSPF and the ISM for more information on determining formal organisational roles and responsibilities.

As part of using a gateway provider’s services, gateway consumers need to understand their own responsibilities, as well as the responsibilities of the other parties involved in delivering the complete gateway solution. This includes understanding each party’s responsibilities for securing the gateway. For example:

• responsibilities for cyber security policy
• incident detection and response
• data retention and backup
• monitoring
• system hardening
• patching and encryption.

In some of these examples, one party may be entirely responsible, or various aspects may be shared between parties.

As part of the IRAP security assessment report for a gateway, IRAP assessors are to document or otherwise identify which party is responsible for managing risks associated with key aspects of each gateway solution in scope of the assessment. This provides gateway consumers with a clear understanding of the different responsibilities that each party has for securing the gateway solution, including their own.

Regardless of the shared responsibility model, gateway consumers remain accountable for their data, including taking steps to ensure the data is appropriately secured. Organisations should verify that gateway controls are in place, operating effectively and providing the required visibility and capabilities. Access requirements should be proportional to the gateway service, and organisations should only provide MSPs and CSPs with the access required to operate the gateway environments.

Tenancy considerations

It is important that multi-tenanted providers exposing interfaces for clients also provide mechanisms for clients’ PEPs to appropriately restrict traffic to only the appropriate tenant or instance. For example, by providing either:

• a unique tenant domain or URL path
• a combination of IP address and port, with a unique HTTP header on all requests
• an SDN construct including unique virtual network interface
• a virtual network route that can be enforced by a PEP on the client side.

If any system component can make an outbound request to an unauthorised or uncontrolled tenancy (even if the client has a valid signed payload), this could enable an outbound command-and-control path that the consumer would be unable to identify or constrain.

Inbound and outbound data flows need to be protected by PEP capabilities. CSPs need to consider, particularly for Software-as-a-Service and Platform-as-a-Service with multi-tenant services, how they will enable each consumer’s own security policy applied across both outbound and inbound data flows. A CSP should support one or more methods. As an example, if the responsibility for some of the security controls falls on the consumer to implement, then the service they are receiving should support a consumer-provided proxy via either a SDN construct (including a gateway load balancer construct as referred to by some CSPs) or application construct (including API-based event bus for policy enforcement).

Cyber security incident reporting

When using a service provider, cyber security incident reporting processes should be formalised through a shared responsibility model. For example, if a security policy violation was discovered through a gateway system, both parties should clearly understand how this will be reported to the appropriate authorities, particularly where there are regulatory or government policy requirements. Organisations should consider contractual obligations to report any cyber security incident or breach to the gateway consumer.

Early detection of a cyber security incident is critical to expediting containment and recovery, including timely reporting to an organisation’s Chief Security Officer or Chief Information Security Officer. The PSPF outlines the requirements and obligations of NCEs for the reporting of security incidents, including cyber security incidents. Refer to the ASD's ISM Guidelines for cyber security incidents.

CSPs, MSPs and their customers will benefit from contract arrangements that clearly define responsibilities.

• CSPs and MSPs, when negotiating the terms of a contract with their customer, should provide clear explanations of the services that the customer is purchasing, services that the customer is not purchasing, and all contingencies for cyber security incident response and recovery.
• Customers should ensure that they have a thorough understanding of the security services that their service provider is providing and address any security requirements that fall outside the scope of the contract. If contracting to an MSP, contracts should detail how and when MSP notifies the customer of a cyber security incident that affects the customer’s environment or data.
• Customers should ensure that they gain trust in the service delivery models provided to them by MSPs and CSPs, particularly with respect to the countries or jurisdictions in which their support service teams may be based.
• Contracts should clearly define sanctions, penalties and exit clauses for not fulfilling contractual terms, noting that penalties rarely compensate an organisation for the losses incurred as a result of a cyber security incident.

The Cloud Security Alliance describes a shared responsibility model as follows:^[3]

In a traditional data centre model, you are responsible for security across your entire operating environment, including your applications, physical servers, user controls, and even physical building security. In a cloud environment, your provider offers valuable relief to your teams by taking on a share of many operational burdens, including security. In this shared responsibility model, security ownership must be clearly defined, with each party maintaining complete control over those assets, processes, and functions they own. By working together with your cloud provider and sharing portions of the security responsibilities, you can maintain a secure environment with less operational overhead.

Gateway visibility and telemetry

Event logs and system telemetry support the continued delivery of operations and improve the security and resilience of critical systems by enabling network visibility. ASD's best practices for event logging and threat detection outlines best practice for event logging and threat detection for cloud services, enterprise information technology (IT) networks, enterprise mobility and operational technology (OT) networks. It also provides recommendations to improve an organisation’s resilience in the current cyber threat environment, with regard for resourcing constraints.

Gateway logs and telemetry may come from a variety of sources:

• systems and applications (e.g. authentications, operational logs, headers and geo-location)
• network infrastructure telemetry (e.g. IPFIX/NetFlow/JFLOW/SYSFLOW)
• traffic payload artefacts (e.g. packet captures of decrypted content and remote object inspection or ‘ICAP’)
• health and performance monitoring tools.

An organisation’s Security Operations Centre (SOC) needs to have access to logs, telemetry and other artefacts produced by their gateways to ensure effective incident response.

High-value operational and audit logs from a gateway need to include traffic to and from:

• identity and authentication systems
• credential and access management systems
• DNS servers
• web proxies
• WAFs
• mail relays
• load balancers
• IPS/IDS
• remote access solutions
• WAN connections
• sandbox and ICAP services
• other security services.

Additionally, network flow telemetry data from gateways can enhance security capabilities.

While full packet capture and storage of all gateway traffic is often impractical, organisations should build the capability to decrypt and store network traffic, where possible, and test the capability to conduct targeted data capture of higher risk sessions and services. This could be achieved either through random sampling or conducted in response to a cyber security incident or investigation. Processes should be developed to provide captured data to the organisation’s SOC, or typically a cyber security incident response team, in a format that facilitates forensic analysis. This data could be in the form of a packet capture file or streamed data.

During a cyber security incident, the availability of logs becomes more important to cyber security incident response teams. Gateways typically have the functionality for logging to be tuned to increase verbosity, which provides more visibility and insights. An organisation should develop and test procedures to increase and decrease log verbosity in response to different scenarios.

An organisation’s SOC will be interested in more than just gateway events. An organisation should also collect and analyse internal network flow telemetry and endpoint event logs (servers and workstations), behavioural analytics of processes, endpoint security logs, and internal security capability events. Figure 11 describes a mechanism where logs and telemetry, generated by multiple gateway services, can be forwarded to several separate stakeholders.

Cyber security incident response plan

Managing responses to cyber security incidents is the responsibility of affected organisations. As such, all organisations should have a CIRP to ensure an effective response and prompt recovery if system controls do not prevent a cyber security incident from occurring. This plan should be regularly tested and reviewed. Organisations can refer to the following guidance when developing their CIRP:&

• ASD's Cyber security incident response planning: Executive guidance
• ASD's Cyber security incident response planning: Practitioner guidance.

Gateways are critical control points between internal systems and the internet and their compromise can disrupt business operations or expose sensitive data. As such, an organisation’s CIRP should include scenarios such as a misconfigured firewall, unpatched mail relays, the case where exploitation is actively occurring without available patch or mitigation, or compromised VPN concentrators, which could be leveraged for lateral movement, data exfiltration, or further compromise of internal environments.

Gateways can help an organisation respond to vulnerabilities. For example, as a temporary measure, a network intrusion prevention system or WAF may be able to actively block known attacks against vulnerable systems that require patching (also called ‘virtual patching’), and firewalls can ingest cyber threat intelligence (CTI) to automatically block sources of malicious traffic.

A gateway service provider’s response to the following questions can indicate their ability to handle cyber security incidents.

Timely service provider support:

• Is the service provider readily contactable and responsive during an incident, and is the maximum acceptable response time captured in the service-level agreement (SLA)?
• Is the support provided locally, from a foreign country, or from several foreign countries?
• Which mechanism does the service provider use to obtain a real-time understanding of the security posture and configuration of the service provider’s services?

Service provider’s CIRP:

• Does the service provider have a CIRP that clearly defines the scope of its incident detection and response responsibilities covering incidents affecting the provider’s underlying infrastructure and explicitly stating whether, and to what extent, this extends to the customer’s use of the service, in a way that is consistent with the ISM’s cyber security incident handling procedures?
• Does the CIRP provide commitments to mandatory reporting under commonwealth law (e.g. Privacy Act 1988, Security of Critical Infrastructure (SOCI) Act 2018, or Cyber Security Act 2024.
• Service provider's track record of responding to previous incidents/vulnerabilities, and how they engaged or communicated to customers, must also be accounted for.
• Can the organisation review the service provider’s CIRP?
• Will gateway services be taken offline for forensics or seized for law enforcement purposes? 

Training of service provider’s employees:

• Which qualifications, certifications and regular information security awareness training do the service provider’s employees receive to know how to use the service provider’s systems in a secure manner, and to identify potential cyber security incidents?

Notification of cyber security incidents:

• Will the service provider notify the organisation through secure communications of cyber security incidents that are more serious than an agreed threshold, especially in cases where the service provider might be liable?
• Will the service provider share data with anyone post compromise, including the service provider's incident response firm/their upstream service providers?

Extent of service provider support:

• To what extent will the service provider assist the organisation with investigations if there is a security breach, such as an unauthorised disclosure of the organisation’s data, or if there is a need to perform legal electronic discovery of evidence?

Access to logs:

How does an organisation obtain access to time-synchronised audit logs and other logs to perform a forensic investigation, and how are the logs created and stored to be suitable evidence in a court of law?

Cyber security incident compensation:

• How will the service provider adequately compensate a consumer if the service provider’s actions or inaction, faulty software or hardware contributed to a security breach?

Data spills:

• If data that an organisation considers too sensitive to be stored in a location is accidentally placed in that location (referred to as a data spill), how can the spilled data be deleted using forensic sanitisation techniques?
• Is the relevant portion of physical storage media securely or irrecoverably erased/destroyed whenever data is deleted? If not, how long does it take for deleted data to be overwritten by consumers as part of normal operation, noting that some service providers have significant spare unused storage capacity?
• Can spilled data be forensically deleted from the service provider’s backup media?
• Where else is the spilled data stored, and can it be forensically deleted?
• For more information refer to the ASD’s Cyber Security Incident Response Planning: Executive Guidance, ASD’s Cyber Security Incident Response Planning: Practitioner Guidance, and ASD’s Cyber Incident Management Arrangements for Australian Governments. 

Architect for maintenance

It is common for vulnerabilities in edge devices to be exploited within hours of a security patch becoming available. An organisation should adopt modern defensible architecture and business processes to ensure patches and mitigations can be deployed with very short notice. Organisations should prioritise unplanned patching outages over the risk of compromise. Where patching is not feasible, gateways may provide organisations with options for compensating controls for vulnerable systems (e.g. WAF or intrusion prevention solution signatures).

Organisations should align change management processes to support unplanned emergency patching scenarios. As DevSecOps processes are more widely adopted in supply chains, organisations should consider if their existing change management processes are introducing barriers for operational teams. For example, CSPs do not have obligation to a consumer’s change management processes, but they do proactively implement processes to patch infrastructure to protect their consumers, which is consistent with the service providers’ shared responsibilities model. For more information refer to the ASD's patching applications and operating systems.

Cyber threat intelligence

A gateway should use CTI to proactively identify and respond to threats and vulnerabilities that are relevant to the consumer(s) of the gateway. A gateway should allow an organisation to both derive and consume CTI from its operation and generate data that allows security analysts to produce CTI. For more information on how to use a gateway to generate and use CTI, refer to the Gateway security guidance package: Gateway technology guides.

Gateways should be architected to generate and use high-confidence CTI. Mature gateways may also be able to take automated responses to security risks based on high-confidence CTI it receives. This can include automatically checking if an Indicator of Compromise (IOC) has been observed or taking action to block an attacker’s IP address or email address.

Some CTI, especially IOCs, can be highly perishable and will only be relevant and actionable for a short time (less than a day, sometimes only hours). CTI should be able to inform organisations of what they should be responding to as a priority. As gateway teams, SOC, and incident response teams have limited resources, organisations should prioritise and consider environmental contexts to assist with triaging CTI. Organisations should make decisions based on CTI (e.g. by changing security settings, adding new security capabilities, changing business processes, adjusting training and policy, or making architectural changes).

Priority services for security visibility

NCEs may choose to consume gateway services through an existing commercial or government gateway provider. While there are many services that gateway providers supply, ASD’s ACSC recommends NCEs prioritise uplifting the security capabilities in the following five services:

• recursive DNS
• web proxies
• mail relays
• reverse proxies
• remote access.

The Gateway security guidance package: Gateway technology guides contain service-specific advice on different types of gateway services (e.g. mail relays, DNS, web proxies and remote access). They also include why organisations should focus on uplifting the security of the above five services.

More information

For more information on topics covered in this guidance, refer to the following ASD’s ACSC publications:

• ASD's Information security manual
• ASD's Patching applications and operating systems
• ASD's Cyber security incident response planning: Executive guidance
• ASD's Cyber security incident response planning: Practitioner guidance
• ASD's Cyber incident management arrangements for Australian governments
• ASD's Foundations for modern defensible architecture
• ASD's Modern defensible architecture

Contact us

Following substantial updates to the Gateway Guidance in September 2026, ASD’s ACSC welcomes feedback to ensure it remains clear, relevant and useful. If you have any questions or feedback, you can write to us or call us on 1300 CYBER1 (1300 292 371).

The Gateway Guidance is being released in parallel with the Department of Home Affairs Australian Government Gateway Security Standard. We encourage interested stakeholders to provide feedback on the Gateway Standard directly to the Department of Home Affairs.

Footnote

1. Non-corporate and corporate Commonwealth entities are government bodies that are subject to the Public Governance, Performance and Accountability Act 2013. More information: Non-corporate Commonwealth entity (NCE) | Department of Finance
2. https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained