How to safely offboard from Portnox Cloud services

In this topic, you will find suggestions for safe offboarding from Portnox Cloud if you no longer want to use Cloud services and, instead, go back to an insecure network, or use a different product/service.

Warning: Safe offboarding depends fully on how Portnox Cloud was implemented in your environment. Because only your internal network engineers and administrators know exactly how the product was configured, used, and maintained, we cannot provide definitive or exhaustive offboarding steps. You may not be using all the services or features listed here, or your setup may differ from standard practices. This list is intended solely as general guidance – it is your organization’s responsibility to evaluate and execute offboarding procedures appropriate to your unique deployment.
  1. Ensure that your devices can connect to networks and other services after offboarding:

    The first and most critical step in offboarding is ensuring that your users retain access to your networks and resources. Before removing any Portnox-related components – such as integrations, certificates, virtual machines, or Docker containers – you must first confirm that all users can still connect to the networks and services that were previously secured with Portnox Cloud, or to replacement networks and services. This can be achieved either by transitioning to a replacement solution or, if necessary, by enabling access through less secure fallback configurations. Only once continuity of access is confirmed should you proceed with the removal of Portnox elements from your environment.

    1. If you were using RADIUS/TACACS+, reconfigure your NAC devices.

      If you were using Portnox Cloud RADIUS or TACACS+ services, removing Portnox configuration from your NAC devices – such as switches, access points, and VPNs – should be treated as a top priority. These devices must be reconfigured either to work with an alternative solution you plan to adopt or, if necessary, to operate in a less secure fallback mode (e.g., no port authorization on Ethernet ports, WPA2/WPA3 Personal SSIDs on access points, or local authentication and authorization for TACACS+).

      Consult your NAC device documentation to learn how to remove existing configurations and how to add new configurations for either your replacement solution or temporary less secure configurations. As a general guideline, on typical network switches you’ll want to:

      • Remove any configured RADIUS or TACACS+ server entries related to Portnox Cloud.
      • Disable or adjust 802.1X port-based authentication if it was enabled for Portnox Cloud.
      • Update VLAN assignments or port security settings if they were tied to Portnox Cloud policies.

      For wireless access points, common tasks include:

      • Removing RADIUS server settings and related authentication profiles.
      • Switching SSID security settings from Enterprise (802.1X) to Personal mode (WPA2/WPA3 Personal) if applicable.
      • Adjusting certificate or client authentication settings that reference Portnox Cloud.

      Since exact steps vary by vendor and model, always refer to your specific device manuals or support resources to ensure proper configuration changes.

    2. If you were using ZTNA, reconfigure all your resources/applications.

      If you were using ZTNA for SSO-enabled web applications, each application must be reconfigured to stop relying on ZTNA for authentication. You can migrate to an alternative SSO provider, such as Entra ID or Google Workspace, or revert to using the application’s built-in login functionality. For any hosted applications that were accessed via ZTNA, external access will no longer be available once ZTNA is removed – unless you implement another remote access method, such as a VPN, to enable connectivity for remote users.

    3. If you were using UEM/MDM solutions, push new profiles.

      If you integrated Portnox with a UEM/MDM solution such as Microsoft Intune or Jamf, it’s essential to review and update any enforced configurations for client devices. These configurations must no longer direct devices to use Portnox RADIUS services, Portnox-issued certificates, or any other Portnox Cloud components. You will need to push new configurations to client devices that align with your replacement solution, or, if applicable, allow devices to connect to fallback networks using less secure methods (e.g., WPA2/WPA3 Personal SSIDs, third-party guest network, etc.).

    4. Reconfigure your client devices.

      If some or all of your client devices were not managed through a UEM/MDM solution, you’ll need to manually update their network configurations, including setting up network interfaces, Wi-Fi profiles, or other relevant settings to connect to your new solution or, if necessary, to less secure fallback networks such as WPA2/WPA3 Personal SSIDs. This also applies if your client device network adapters were configured using AgentP.

  2. Remove integrations with Portnox Cloud.

    During your initial onboarding with Portnox Cloud, it’s likely that you integrated it with other systems – such as authentication providers (e.g., Entra ID, Google Workspace, Okta), UEM/MDM solutions (e.g., Intune, Jamf), SIEM platforms, and others. While removing these integrations is not required for maintaining network access or service continuity, and they will cease functioning once your Portnox Cloud tenant is decommissioned, it is strongly recommended to clean them up as part of good housekeeping and to avoid unnecessary clutter or confusion in your environment.

    The exact steps for removing these integrations will vary depending on the specific solutions involved. For example, in Azure, you should remove any Portnox-related applications from your Entra ID tenant. In SIEM platforms, you may need to delete configured log sources and any associated resources, such as virtual machines or syslog forwarders. Refer to the documentation of each integrated product to ensure all Portnox-related components are properly removed.

  3. Remove Portnox virtual machines, Docker containers, and AD Broker instances.

    You may have virtual machines or Docker containers running Portnox-related services – such as local RADIUS, local TACACS+, ZTNA, or components used for integrations like SIEM – hosted either in your physical infrastructure or in a cloud environment. You may also have AD Broker services running in the background on local virtual or physical machines. Be sure to identify, stop, and remove all such instances.

    While these services will no longer function once your Portnox Cloud tenant is decommissioned, they may still consume resources. If they are cloud-hosted, you may continue to incur charges; if they are running locally, they will continue to occupy system resources unnecessarily.

    If you are using cloud platforms, also remove any additional services that were provisioned specifically for Portnox Cloud – for example, in Azure, remove virtual networks, public IP addresses, log configurations, and other related infrastructure components that were created to support container instances running Portnox Docker containers.

  4. Remove AgentP from client devices.

    If your devices were previously managed using AgentP, you should uninstall AgentP. While AgentP will stop functioning once your tenant is decommissioned and poses no security risk if left installed, it is recommended to uninstall it for housekeeping purposes and to free up disk space and reduce clutter.

  5. Remove Portnox supplicant certificates from client devices.

    If you issued Portnox certificates to client devices – whether distributed manually, via a UEM/MDM solution through SCEP, or through self-onboarding – you can now remove them as part of housekeeping. When your Portnox Cloud tenant is decommissioned, the tenant’s Certificate Authority (CA) will no longer exist, causing all issued certificates to stop working completely. Although these certificates pose no risk if left on devices, they are unnecessary and it’s best to remove them. There is no need to revoke any supplicant certificates, since without the CA, the certificates become invalid automatically.

    Remove the Portnox tenant CA certificate from client devices, if present in the root certificates category, as it will no longer be valid or needed once the tenant is decommissioned. However, do not remove the DigiCert Trusted Root G4 certificate, the G2 certificate, or any other industry-standard CA certificates used to sign a wide range of certificates beyond Portnox. Removing these trusted root certificates may impact access to other services and cause broader connectivity or trust issues in your environment.

  6. Decommission your Portnox Cloud tenant.

    As the last step, coordinate with your Portnox contact to request the decommissioning and deletion of your tenant. Keep in mind that tenant deletion is permanent – if you choose to return to Portnox Cloud in the future, you will need to create a new tenant and begin the onboarding process from the beginning.