Portnox Cloud best practices

Authentication repositories

Should I use manual or automatic provisioning for an authentication repository?

• Most of our customers use automatic provisioning. We recommend starting with automatic provisioning. If it does not meet your requirements, you can remove it and switch to manual provisioning.

• The choice between automatic and manual provisioning is available only for the Entra ID authentication repository. For Google Workspace, only automatic provisioning is supported, while Okta always requires manual provisioning using the REST API or LDAP.

Can I use a hybrid configuration with Active Directory and Entra ID?

• Yes, you can configure Portnox Cloud to work with both Entra ID and Active Directory. However, by default, Entra ID takes precedence. Users and devices found in Entra ID bypass synchronization with on-premises AD.

• If you use AgentP with unattended enrollment, you can override this behavior by enabling the option to prefer on-premises AD over Entra ID.

How many Portnox LDAP Brokers should I use?

• We recommend deploying at least two Portnox LDAP Brokers if you use Portnox Cloud with Active Directory or an on-premises LDAP directory. If an LDAP Broker becomes unavailable for any reason, you will lose the ability to authenticate on the network and more. The LDAP Broker is lightweight and easy to deploy.

How do I deploy LDAP Broker securely?

• We strongly recommend treating LDAP Broker as a Tier 1 application because it requires high-level permissions in the local AD or LDAP directory to function. A compromise of the LDAP Broker could give an attacker full control over your local directory.

Cloud RADIUS and local RADIUS

Should I use only Cloud RADIUS servers or local RADIUS?

• We recommend a hybrid setup, which is used by most of our customers: deploy local RADIUS servers, configure them as the primary servers on your NAS devices, and optionally configure Cloud RADIUS servers as secondary servers. While it is possible to configure Cloud RADIUS as primary servers, this can slow response times, especially during outages, because the NAS will first attempt to contact the Cloud and only switch to the local RADIUS if the Cloud is unreachable.

• If you configure only Cloud RADIUS servers, an Internet outage will prevent local users from logging in to the local network. We recommend this approach only if you have no local resources (i.e., all resources are cloud-based) and your local network exists solely to provide Internet access.

How many local RADIUS servers should I use?

• We recommend deploying at least two local RADIUS servers. They are inexpensive to run, and having multiple servers ensures redundancy if one fails.

• The number of local RADIUS servers depends on the capabilities of your NAS devices. Some NAS devices limit the number of RADIUS servers you can configure. If you also configure Cloud RADIUS servers, they may take available configuration slots, reducing the number available for local RADIUS servers.

Should I run a local RADIUS server in a VM or Docker?

• We recommend running local RADIUS servers in Docker because it is easier to set up and uses fewer machine resources.

• The advantage of virtual machines is that the local RADIUS server is updated automatically. To enable automatic updates for a Docker-based local RADIUS server, you need to deploy the portnox-autoupdate Docker container.

• If you prefer using virtual machines, for example, due to network or firewall configurations, the local RADIUS server can run on all major virtual machine platforms.

Does it make sense to run a local RADIUS server in a cloud service?

• While it is possible to configure a local RADIUS server in a cloud service (and we provide instructions on how to do this on Azure, AWS, and Google Cloud), we recommend running the local RADIUS server on-premises only, as most of our customers do. Its primary purpose is to provide connectivity during Internet outages, and placing it in a cloud service would make it inaccessible during such outages.

• If your goal is to enhance security by running a local RADIUS server in the cloud, this is unnecessary. The local RADIUS server connects to Portnox Cloud using fully secure TLS communications, and you can also configure Cloud RADIUS with RadSec to ensure fully encrypted RADIUS communication.

Should I use RadSec if it is available on my NAS device, or is RADIUS secure enough?

• Most of our customers use RADIUS without RadSec. The RADIUS protocol supports different authentication methods. The methods we recommend (see below), such as EAP-TLS and EAP-TTLS, are fully secure even without RadSec because they never transmit credentials in plain text.

• If you must use credential-based authentication with a less secure method such as PEAP, for example, if your authentication repository does not support stronger methods and you prefer not to use certificates, we recommend configuring RadSec to prevent credential leakage through man-in-the-middle attacks.

• Regardless of the EAP methods used, if your devices support RadSec, the only drawback is increased configuration complexity. This is especially true for RadSec mutual authentication, which requires uploading the device’s root certificate to Portnox Cloud.

Authentication methods

Should I use certificates, credentials, or MAC-based authentication?

• We strongly recommend using certificates for authentication (the EAP-TLS method for RADIUS/802.1X). Certificates are supported on all major platforms, provide a much higher level of security than credentials, and are compatible with all authentication repositories.

• If you must use credentials, be aware that many authentication repositories do not support highly secure credential exchange. For example, Google Workspace requires users to create individual app passwords for credential-based authentication, which makes onboarding time-consuming and complex. Entra ID only supports EAP-TTLS, which is less secure than PEAP-MSCHAPv2 supported by on-premises directories such as Active Directory. Therefore, credentials should be used only when absolutely necessary, and preferably only with on-premises authentication repositories.

• MAC-based authentication should be treated as a last resort, only for devices that do not support other methods, such as some IoT devices. It is not fully secure because MAC addresses can be spoofed. While Portnox Cloud provides MAC spoofing detection, MAC-based authentication remains less secure than using certificates or credentials.

Should I use user certificates or device certificates?

• Your choice depends on how your devices are used. For mostly individual devices or devices that support user accounts and are shared among multiple users, we recommend using user-based certificates for authentication.

• For devices that do not support user accounts, such as kiosks, scanners, and similar devices, device-based certificates are preferable, as you cannot identify the individual using the device.

• Device authentication is available only with Entra ID, Active Directory, or on-premises LDAP directories. Google Workspace and Okta do not support device accounts. If you want to use device-based authentication with Google Workspace or Okta, Portnox Cloud must create local Portnox accounts for the devices, requiring you to manage these devices directly in Portnox Cloud instead of your usual authentication repository.

Should I use Portnox certificates or my own certificate authority?

• We strongly recommend using the certificate authority provided by Portnox Cloud for ease of configuration. While Portnox Cloud allows you to upload your own CA certificate and issue certificates to users and devices, this places the entire certificate management process on you. Portnox Cloud cannot directly use your CA; it can only verify whether the certificates presented by devices are valid. You are then responsible for managing all device configuration processes and certificate issuance, including providing your own SCEP server or alternative methods to distribute certificates to all devices.

Agent-based and agentless onboarding

Should I use AgentP or can I authenticate and configure my devices without it?

• Most customers use AgentP because it simplifies device configuration and provides additional benefits, such as risk assessment. We highly recommend using AgentP.

• If you already use a Unified Endpoint Management (UEM) or Mobile Device Management (MDM) platform, such as Intune, Jamf, or others, you can obtain certificates from Portnox Cloud via the SCEP protocol and deliver them to devices, as well as configure device interfaces to use these certificates. However, this process is more complex than using AgentP, and while many UEM platforms have been tested, not all fully support SCEP.

• If you want to use risk assessment without AgentP, you must use Intune or Jamf. These are the supported platforms for providing risk assessment information to Portnox Cloud. You can also assess risk using other supported platforms, such as SentinelOne, which works together with Intune to deliver risk information to Portnox Cloud, enabling you to decide whether to limit network access when risk levels are high.

Should I use single-user, multi-user, or device onboarding with AgentP?

• If the device supports multiple users, for example, a Windows desktop used by several employees, such as a reception computer, use multi-user onboarding with AgentP. This allows Portnox Cloud to assign different certificates and access rights for each user (user authentication) and separate certificates and access rights when no user is logged on (computer authentication). Note that this requires Windows integrated with Entra ID or Active Directory.

• If the device is a personal device used by a single user, such as a personal laptop, use single-user authentication. The device will always retain the access rights of that user.

• If the device is not tied to any users, such as a self-service kiosk, use device-based authentication because the actual user cannot be identified.

Should I distribute AgentP to all the machines in my networks?

• We recommend distributing AgentP using your existing UEM/MDM software, such as Intune or Jamf, just as you use these platforms to manage other applications on users' devices. If you use Windows with Entra ID or Active Directory, the user onboarding process is fully automated because AgentP can retrieve user information directly from the operating system integrated with the same authentication repository. For other repositories and operating systems, users must manually log in to the authentication repository to start using AgentP.

• If automatic distribution is not possible, or if users have BYOD devices, they can download AgentP directly from the web or app stores, install it easily, and log in to the authentication repository to get AgentP fully operational in under a minute.

Network device configuration

Should I configure NAS devices in any special way to work best with Portnox Cloud?

• We strongly recommend checking whether your device supports a feature often called critical authentication or critical VLAN, and configuring it if available. Refer to your device manual to determine support and setup instructions. This feature allows users to connect to the local network even during a RADIUS failure, such as an Internet outage (if no local RADIUS is configured) or a local RADIUS outage (especially if only one local RADIUS is used). Essentially, if the device cannot reach any configured RADIUS servers, it will still allow user connections to the local network but assign them to a special VLAN with limited privileges.

• We strongly recommend using the Portnox Cloud monitoring mode when testing new NAS device configurations. Monitoring mode does not lock anyone out of the network, but lets you observe connections to ensure correct setup. After monitoring user behavior for a short period, you can disable monitoring mode.

Portnox groups and policies

What is the best way to set up Portnox groups?

• We strongly recommend keeping the Default group as a catch-all or radar group. Configure this group with minimal access rights (for example, only Internet access and no local resources) and allow any authenticated devices or users to initially connect here. Periodically review who ends up in this group and assign them to higher-access groups as needed. Especially during testing or early onboarding, this approach simplifies deployment and accelerates onboarding.

• Create only the minimum number of groups required with different privileges. While having more groups does not negatively affect Portnox Cloud performance, it increases management complexity, making mistakes and troubleshooting more likely.

What is the best way to set up Portnox policies and sites?

• We strongly recommend keeping the number of policies to a minimum. Although many policies do not impact Portnox Cloud performance, they increase management complexity and the risk of human error.

• Use sites only when necessary, primarily for site-level identification in alerts or troubleshooting. Adding sites increases management complexity and the likelihood of mistakes.

Migration

What is the best way to migrate from the current network setup to a setup based on Portnox Cloud?

• When migrating Wi-Fi connections, we strongly recommend creating a parallel SSID:

  • Keep the legacy SSID active while introducing a new 802.1X-secured SSID.

  • Push new SSID profiles to managed devices via AgentP, UEM/MDM software, or GPO.

  This approach provides a safe runway for testing before retiring the old SSID.

• If absolutely necessary, you can reuse the existing SSID while changing its authentication method to Portnox RADIUS. This requires all devices to be pre-provisioned with certificates and proper configurations, for example, using AgentP, UEM/MDM software, or GPO. Note that this approach carries a higher risk of service disruption. We strongly recommend keeping a fallback SSID available during cutover.

What is the best-practices migration process?

1. Planning

   1. Inventory current SSIDs, VLANs, ACLs, DHCP scopes, etc.

   2. Document any existing authentication methods and segmentation policies.

   3. Define migration goals (e.g., move to certificate-based authentication).

2. Lab testing and pilot roll-out

   • Create a test SSID using the Cloud RADIUS.

   • Validate authentication and connectivity across required device types (Windows, macOS, iOS, Android, IoT).

   • Confirm correct VLAN assignment and fallback behavior during RADIUS downtime.

   • Ensure that the monitoring mode is enabled on NAS devices to log issues without blocking access.

   • Start with IT staff or early adopters.

   • Use the Devices page and Alerts in Portnox Cloud to monitor authentication results.

3. Staged deployment

   • Once comfortable with the testing, expand the migration department-by-department or site-by-site.

   • Ensure all managed devices have AgentP installed or the necessary SCEP profiles pushed from UEM/MDM software before cutting over.

   • If the devices aren’t using certificates, ensure the necessary MAC addresses are whitelisted in Portnox.

4. Validation

   • Confirm RADIUS responses and redundancy.

   • Validate certificate delivery workflows (AgentP, SCEP, UEM/MDM).

   • Check that the correct VLANs and policies are applied per group.

5. Legacy SSID retirement

   • Disable old SSIDs only after confirming full coverage.

   • Ensure fallback/quarantine VLAN exists for stragglers, if necessary.

6. Post-migration cleanup

   • Turn off the monitoring mode for all NAS devices gradually.

   • Remove obsolete SSIDs and unused configurations.

   • Audit NAS devices for consistency.

   • Update any internal documentation to reflect the new SSID structure and Portnox policies.