Portnox Cloud best practices

Automatic provisioning registers the Portnox Cloud application in your Entra ID tenant for you, so it needs less setup. Manual provisioning gives you granular control over the application privileges that the Portnox Cloud integration has in your Entra ID tenant. Most of our customers use automatic provisioning, and we recommend starting with it. If it does not meet your requirements, you can switch to manual provisioning, but you must delete the existing integration first and redo the integration process from scratch.

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.

Government Entra ID tenants do not allow automatic app creation, so manual provisioning is the only option for these tenants.

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 activating the Settings > Services > GENERAL SETTINGS > AgentP Enrollment Policy > Prefer Active Directory over Entra ID during unattended enrollment checkbox.

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.

You can install any number of LDAP Broker instances on any number of machines. For domains with multiple brokers, Portnox Cloud load-balances authentication requests across all configured instances.

The Portnox LDAP Broker should be treated as a Tier 0 asset; access should be restricted to Tier 0 admins using PAWs and governed by Tier 0 network and security policies due to its direct interaction with Active Directory and authentication processes.

The required privilege level for the broker’s AD user account depends on your authentication configuration:

• Standard NTLM authentication (default): the service account needs only standard read-only access to the directory. No admin privileges are needed.
• NTLMv2-only authentication: the service account needs either membership in a Domain Admins-level group, or dedicated replication permissions equivalent to reading all directory changes.

Even in the default, read-only configuration, the service account still has broad read access to the entire directory structure. The Tier 0 classification therefore applies regardless of which authentication mode is in use.

Some customers, especially those subject to GDPR or other privacy regulations, prefer to minimize personally identifiable information (PII) stored in integrated systems. In Portnox Cloud, the only PII stored are user account names or device names that connect to Portnox Cloud services.

A common way to achieve this is by configuring user accounts in your identity provider, such as Entra ID, Google Workspace, or Okta, so that the User Principal Name (UPN) is a non-identifiable random string. You can associate an email alias with the UPN containing the actual user name for convenience. When Portnox Cloud synchronizes authentication data, it receives the obfuscated UPN instead of a name-based identifier. This ensures that even if authentication data is synced, Portnox Cloud only stores anonymized identifiers rather than real names. Note that this configuration is done entirely in your identity provider, not within Portnox Cloud.

If concerned about the security of your PII, please note that Portnox Cloud data is hosted on Azure infrastructure, similar to services like Entra ID, so any PII already present in your identity provider benefits from comparable infrastructure-level protections.

Cloud RADIUS is the recommended authentication service for most deployments. Use local RADIUS servers if your environment requires continued local network access during Internet outages, or requires Change of Authorization (CoA) or protection against RADIUS packet fragmentation (see the tradeoffs below). Without a local RADIUS server, any device that is not already connected will fail to authenticate during an outage, because authentication requests cannot reach the Cloud back-end. If all resources are cloud-based and the local network exists solely to provide Internet access, Cloud RADIUS alone is sufficient and significantly reduces deployment complexity.

The following table summarizes the tradeoffs between using Cloud RADIUS and using local RADIUS servers.

We recommend deploying at least two local RADIUS servers. This gives you redundancy, and local RADIUS servers are inexpensive to run.

Beyond two, the right number depends on:

• The structure of your environment: an organization with several branch sites often needs at least one local RADIUS server per site, so a site does not lose authentication if its own Internet connection goes down.

• How many RADIUS servers your NAS devices allow you to configure: some NAS models accept only two or three RADIUS server entries, which caps how many local RADIUS servers you can add.

We recommend running local RADIUS servers in Docker because it is easier to set up and uses fewer machine resources. It also supports CoA functionality (virtual machines do not).

In most cases, no.

Although local RADIUS is supported in many cloud environments such as Azure, AWS, and Google Cloud, a cloud-hosted deployment does not provide the main benefit of local RADIUS for an on-premises network. It is not locally reachable during an Internet outage and therefore cannot provide access to the local networks during such an outage.

In this design, local RADIUS mainly acts as a customer-managed proxy that forwards authentication requests through a TLS connection to the Portnox Cloud back end. For most customers, this provides little or no advantage over pointing their network devices directly to Cloud RADIUS.

A cloud-hosted local RADIUS adds a recurring monthly cloud cost, deployment complexity, and another component for you to manage in your cloud environment. It does not increase security, adds an extra network hop that may slow down connections, and can make logs harder to access depending on the cloud platform and how the service is deployed.

For these reasons, use Cloud RADIUS directly unless there is a specific requirement for a customer-managed RADIUS proxy, such as routing, firewall, or compliance. When outage protection for an on-premises network is required, deploy local RADIUS on-premises.

The main drawback of RadSec is increased configuration complexity. Most customers use RADIUS without RadSec when using secure EAP methods such as EAP-TLS and EAP-TTLS because with these EAP methods, sensitive information is already sent using a TLS tunnel so RadSec provides no extra security benefits. RadSec is recommended only if using less secure credential-based methods such as PEAP, or if you run into packet fragmentation issues, for example with large certificates.

Note that deploying a local RADIUS server also addresses concerns about unencrypted RADIUS traffic traversing the Internet, as it communicates with the Cloud back-end over HTTPS rather than sending RADIUS packets over the Internet, while additionally providing outage resilience that RadSec cannot offer. Because it uses a different protocol to reach the Cloud back-end, a local RADIUS server also avoids packet fragmentation issues.

There are four main configurations for assigning RADIUS server priority on NAS devices. Each has trade-offs, and the right choice depends on your environment and priorities – whether that is simplicity, outage resilience, fast reconnections, or redundancy against local infrastructure issues. Review the options below and decide based on what matters most to your deployment.

We strongly recommend using certificates for authentication using EAP-TLS. Certificates are supported on all major platforms, provide a much higher level of security than credentials, and are compatible with all authentication repositories. Unlike credentials, certificates cannot be phished, guessed, or reused by an attacker who intercepts them, since authentication relies on a private key that never leaves the device.

Credentials should be used only when absolutely necessary, and preferably only with on-premises authentication repositories. This is because many cloud authentication repositories only support weaker credential-based EAP methods. For example, Google Workspace requires users to create individual app passwords for credential-based authentication, which makes onboarding time-consuming and complex, and Entra ID only supports EAP-TTLS, which is secure, but not as strong as the PEAP-MSCHAPv2 method supported by on-premises directories such as Active Directory.

MAC-based authentication should be treated as a last resort, only for devices that have no support at all for 802.1X or WPA Enterprise, and where no other option is available. A MAC address can be spoofed on any PC with no special tools, so an attacker can disconnect an approved device and connect their own device using the same MAC address to gain the same network access. This makes MAC-based authentication a common attack surface. While we support IoT fingerprinting, which detects most such attempts, it does not fully close this attack surface: fingerprinting recognizes device types, not individual devices, so an attacker using a device of the same model as the legitimate one can still produce a matching fingerprint.

Before resorting to MAC-based authentication, check if your device and access point support IPSK (Identity Pre-Shared Key). IPSK allows multiple pre-shared keys on the same SSID, with each key linked to a specific device or user. For example, an IoT device that only supports WPA Personal, connected to an access point that supports IPSK, gets stronger authentication than MAC-based authentication alone, since connecting requires both the correct MAC address and the correct key. IPSK is not as secure as 802.1X and requires more management overhead, but it is better than no authentication check at all.

In most cases, no. Use EAP-TLS as recommended above unless you are migrating from an existing Cisco Identity Services Engine (ISE) environment that already authenticates using EAP-TEAP.

EAP-TEAP provides a security benefit over plain EAP-TLS: it authenticates both the device certificate and the user credentials together in a single exchange, giving you assurance that both the machine and the person using it are verified. However, this benefit comes with significant practical costs that make EAP-TEAP a poor default choice for most new deployments. EAP-TEAP is much more complex to configure, it is currently supported only on Windows 10 and Windows 11, it is only usable with an Active Directory repository if either inner method is PEAP-MSCHAPv2 rather than EAP-TLS, and it is difficult to distribute at scale through standard MDM/UEM solutions except Group Policy. Among mainstream MDM platforms, only Microsoft Intune supports it, and even then only for wired connections, while wireless connections still require manually building and importing an XML profile.

For organizations migrating from Cisco ISE, these costs are usually already justified, since EAP-TEAP is the default authentication method in most Cisco ISE deployments, and organizations moving to Portnox Cloud can often keep their existing device configuration, certificates, and GPOs unchanged. For organizations without this pre-existing investment, EAP-TLS provides equivalent certificate-based security with far less complexity, broader OS and repository support, and much easier distribution through standard MDM/UEM tools.

For more information, see the following topics: EAP methods and their security and EAP-TEAP requirements, limitations, and FAQ.

We recommend that you use user certificates for personal or shared devices, and device certificates for kiosks and devices with no user account.

If your authentication repository is Entra ID, Active Directory, or on-premises LDAP, it stores both user accounts and device accounts. Device authentication works just as well as user authentication. Portnox Cloud syncs devices from the authentication repository the same way it syncs users.

With Google Workspace (GWS) or Okta, the authentication repository stores only user accounts, not devices. Some people point to the device list in the GWS Chromebook extension UI as a counterexample, but that list isn’t part of the authentication repository. When Portnox Cloud synchronizes with GWS or Okta, it only gets users. It has no visibility into the devices those users manage. You can still authenticate devices here, but it comes with tradeoffs.

The UEM/MDM software can still request a SCEP certificate for the device, and that certificate is valid, since the tenant root issues it. Portnox Cloud validates the certificate in EAP-TLS, then reads its Subject and SAN fields to find out which user or device it belongs to:

• With Intune and Entra ID, this works well. The cert contains the Intune ID. The device is in Intune, and it’s also in Entra ID. So Portnox Cloud matches it to the authentication repository record right away, and assigns the correct group and privileges during authentication.

• With GWS or Okta, there’s no authentication repository record to match. If you turn on agentless auto-onboarding with certificates, Portnox Cloud accepts any certificate it can validate. When it can’t match the certificate to an entry in the repository, it creates a new Portnox account instead, and names this account using the Subject field of the certificate. So if your SCEP certificates have the device serial number in the Subject, your Portnox devices list shows serial numbers. You can use the FQDN or any other value instead, as long as the UEM can put that value in the certificate using a UEM-specific variable.

This convenience has a cost. Compare it to Entra ID:

• Device removal: With Entra ID, when you remove a device, Portnox Cloud removes it from its synced repository too, right away. The device can no longer authenticate. With GWS or Okta, this is impossible. So when you remove a device there, its Portnox account stays untouched. The device keeps its network access, just like before. You must delete or block that account in Portnox Cloud yourself. This means that you must manage device lifecycle in two places: GWS or Okta, and Portnox Cloud.

• Grouping: With a synced authentication repository, devices can belong to repository groups (Entra ID groups, for example). You can map these groups to different Portnox groups, so devices in Finance get different access than devices in HR. With GWS or Okta, there is no such group data for devices. Portnox Cloud puts every auto-onboarded device in the same group. To split devices into different groups, you must move each Portnox account by hand, one at a time.

We recommend using the certificate authority provided by Portnox Cloud for ease of configuration and management. Use your own certificate authority only if you already use this authority for other purposes. However, be aware that if your CA’s private key is compromised, you will need to upload a new CA certificate and regenerate all supplicant certificates verified by Portnox.

If you use your own CA, Portnox Cloud only verifies that a device’s certificate was issued by your CA, by checking it against your CA’s certificate, which you upload to Portnox Cloud. Portnox Cloud does not issue, track, or manage any certificate on your behalf. You are responsible for:

• Issuing every user and device certificate yourself, since Portnox Cloud does not have your CA’s private key and cannot generate certificates for you.

• Running and maintaining your own SCEP server, or another method of your choice, to distribute certificates to devices.

• Tracking certificate validity and renewal yourself, since Portnox Cloud cannot monitor or track the validity of certificates it did not issue.

This is a lot of extra work, and it does not make Portnox Cloud more secure. Using your own CA makes sense only if you already run this CA infrastructure for other purposes. Otherwise, use the CA provided by Portnox Cloud.

We recommend using AgentP. It provides three advantages that are difficult to get any other way:

• More visibility into the device: with AgentP installed, Portnox Cloud can see the device type, operating system, user, IP address, system configuration, installed applications, and more. You can see all this information directly in Portnox Cloud, and you can also build detailed risk conditions based on it.

• Simpler onboarding across platforms: with a UEM or MDM, you need to configure them to issue SCEP certificates and create separate network profiles for each platform. AgentP handles both the certificate and the network configuration. Installing and distributing AgentP through a UEM or MDM is also less complex and less error-prone than creating SCEP and network profiles, and not every UEM or MDM supports SCEP for all platforms.

• More detailed risk policies: other platforms, such as Intune, Jamf, and CrowdStrike, can also assess device risk, and Portnox Cloud can use their assessment. However, without AgentP, Portnox Cloud can only act on the overall decision that platform provides. With AgentP, Portnox Cloud has access to detailed, individual conditions, such as a specific outdated application or a disabled disk encryption setting, and you can build fine-grained risk policies and groups directly in Portnox Cloud, instead of managing all conditions in the other platform.

Some organizations hesitate to deploy AgentP because they already run several agents on their devices and want to avoid adding another one. AgentP is a small, lightweight agent, and the visibility and control it adds are worth the extra footprint.

• Single-user mode: use this mode for computers used by a single person, such as personal laptops, where the computer does not need network access when the user is logged out.

  In this mode, AgentP identifies and authenticates the user who is currently logged in. Every new user who logs in must onboard AgentP manually. When the user logs out, the computer has no network access.

  We do not generally recommend this mode. Most computers need network access even when no user is logged in, for example to receive automatic updates or to allow an administrator to log in remotely.

• User-based multi-user mode: use this mode for a computer used by a single person, such as a personal laptop, that needs to keep network access even when the user is logged out. You can also use this mode on shared computers, but multi-user mode is recommended instead.

  In this mode, AgentP identifies and authenticates the user who is currently logged in. It installs the user’s certificate in both the user store and the computer store. When the user logs out, the computer keeps network access using that certificate, so it keeps the privileges of the last logged-in user. On a shared computer, this means the computer’s access after logout reflects whichever user logged in most recently.

  We recommend this mode for computers used by a single person, or alternatively for devices with several users if you do not want to manage those devices inside Portnox Cloud. This is because creating device certificates, as in true multi-user mode (see below), requires device accounts in Portnox Cloud, and these can only be synced with your repository if the repository supports devices, such as Entra ID or Active Directory. If your repository does not support device accounts at all, such as Google Workspace or Okta, you can still use devices and device certificates, but during onboarding they are created in Portnox Cloud as Portnox accounts, so you have to manage all devices entirely inside Portnox Cloud.

• Multi-user mode: use this mode for shared computers with more than one regular user.

  In this mode, AgentP installs the certificate of the currently logged-in user in the user store, and a separate computer certificate in the computer store. When the user logs out, the computer uses the computer certificate, which typically has more limited access, such as Internet-only access.

  We recommend this mode for most deployments. However, if you use a repository that does not support device accounts, such as Google Workspace or Okta, your Portnox device accounts are not synced with the repository, and are instead onboarded as Portnox accounts. This means you have to manage all your devices inside Portnox Cloud, and cannot manage them inside your repository. If you use Entra ID, Active Directory, or on-premises LDAP, you can manage devices inside the repository, and this is not a problem.

• Kiosk mode: use this mode for computers that have no individual users at all, such as kiosks.

  In this mode, AgentP installs only a computer certificate and uses it for all network access. No individual users are recognized.

  We fully recommend this mode when there is no specific user for the device. As with multi-user mode, if your authentication repository does not support device accounts, all your device accounts are onboarded as Portnox accounts, so you have to manage them inside Portnox Cloud instead of inside your authentication repository.

We recommend distributing AgentP using existing UEM or MDM software. Users can also manually install AgentP on BYOD devices.

When you push AgentP through a UEM or MDM without further configuration, the UEM or MDM only installs the AgentP application. It does not onboard the device. The user must still open AgentP and onboard manually, for example by clicking their authentication repository’s logo and signing in with their credentials.

You can avoid this manual step in some cases:

• On a Windows computer already joined to Entra ID or Active Directory, AgentP can read the identity the operating system already uses for that repository, and onboard using it directly, without showing the onboarding screen to the user.

• On other platforms, or where the device is not joined to the repository, you can still automate onboarding, but it takes more setup. Configure your UEM or MDM to distribute a SCEP certificate to the device before AgentP is installed. Then distribute a script that creates a small configuration file in a specific location that AgentP checks during installation. This file names the certificate issuer. When AgentP runs for the first time, it looks for this configuration file, finds a certificate on the device that matches the issuer named in it, and onboards automatically using the identity from that certificate.

If you use a UEM or MDM, we recommend setting up this SCEP-and-script automation where possible. If you are fine with users onboarding manually, that is not a problem either, since it is a one-time action: the user opens AgentP and signs in with their existing credentials, for example through Entra ID or Google Workspace.

The same manual onboarding option is available to BYOD users. Anyone who installs AgentP on their own device and can sign in to your authentication repository will be able to onboard and receive a certificate. If you want to restrict this, use policies to give unmanaged or unrecognized devices only minimal access, or block them outright.

Outdated or unmanaged devices should be blocked first and optionally deleted later. Deleting without blocking allows re-enrollment and network access.

Yes. We strongly recommend that you set up critical authentication (also called: critical VLAN, critical auth VLAN, fallback VLAN, authserver timeout VLAN, or auth service-unavailable VLAN). Without it, if a NAS device cannot reach the Portnox Cloud RADIUS servers, for any reason, including an Internet outage or bad configuration, devices get no network access at all.

If you set up critical authentication, then if the NAS cannot reach the RADIUS servers, it assigns devices to a special VLAN. In most cases, you can give that VLAN access to Internet and, for example, printers. This way, users can still use the Internet and basic local services, even when there is a problem with the network setup.

You should do the same for devices that fail authentication. Instead of blocking these devices from the network, put them in a quarantine VLAN. You can decide that a device in a quarantine VLAN can still use low-risk services, such as the Internet or local printing, even when something is set up wrong.

We strongly recommend keeping the Default group as a catch-all, sometimes called a radar group. Give it minimal access, for example, Internet access only, with no access to local resources. Let any authenticated device or user connect here first. Then check who ends up in this group from time to time, and move them to a group with more access if they need it. This approach is especially useful during testing or early onboarding, since it simplifies deployment and speeds up onboarding.

Create only the minimum number of groups you need for different access levels, for example one group per department or one group for administrators and one for everyone else. Having more groups does not slow down Portnox Cloud, but it does add management overhead: more groups means more chances for mistakes, and it makes troubleshooting harder.

Keep the number of policies to a minimum. Portnox Cloud limits how many policies you can create (see What are accounts, groups, policies, and sites?). Staying well under these limits also keeps your setup easier to understand and troubleshoot. If you don’t assign a specific risk assessment policy to a group, Portnox Cloud uses the System Default Policy, so you only need to create additional policies for groups that genuinely need different rules.

Use sites only when necessary. A site represents a physical location, such as an office, and its only site-specific setting is which access control policy applies to NAS devices there. Create a site only if a location genuinely needs its own access control policy. If all your locations should behave the same way, you don’t need separate sites for them.

We recommend creating a new, parallel SSID for Portnox Cloud, rather than reconfiguring your existing SSID in place. With a parallel SSID, your current network keeps working without interruption while you test and roll out Portnox Cloud, and you can move users and devices over gradually instead of all at once. If something goes wrong during testing, users can simply keep using the existing SSID.

Reusing the existing SSID and reconfiguring it for Portnox Cloud is possible, but it carries more risk. Any misconfiguration affects everyone on that SSID immediately, since there’s no working fallback network to fall back on. Client devices may also have cached settings or a fixed connection profile for that SSID, which can behave unpredictably once the underlying authentication changes, for example continuing to trust old cached credentials or failing to pick up new settings automatically.

Once you’ve fully migrated to the parallel SSID and confirmed it works for all your device types, retire the legacy SSID.

1. Select the VM-based local RADIUS server to replace.

   If you have multiple VM-based local RADIUS servers, migrate them one by one: complete the full process for the first server before starting the next.

2. Change the priority of RADIUS servers in NAS device configurations so that Portnox Cloud RADIUS is the primary server, not the VM-based local RADIUS.

   Note:

   If you can’t use Cloud RADIUS servers, simply leave one VM-based local RADIUS server running while you migrate the others and use that server as your primary RADIUS during migration.
   Note:

   Optionally, you can configure NAS devices to accept Change of Authorization (CoA) packets if required by following the NAS switch documentation on CoA. This is not directly related to migration, but Docker-based local RADIUS servers give you that option.

3. Turn off the selected VM-based local RADIUS server. Do not delete it yet; keep it powered off in case you need to roll back.

4. Deploy the Docker-based local RADIUS server:

   • Create the Docker-based local RADIUS server by following the guide.

   • Assign the same IP address, ports, and shared secret as the VM-based server. This minimizes NAS configuration changes and reduces the risk of errors.

5. Confirm that the Docker-based local RADIUS server shows as Active in the Portnox Cloud portal.

6. Update NAS device RADIUS server priority to point to the Docker-based local RADIUS instance as the primary server.

   Note:

   If you kept the same IP, ports, and shared secret, you can revert to the previous configuration if your NAS devices give you such an option. Otherwise, simply adjust the priority again.

7. Repeat this process for each remaining VM-based local RADIUS instance.

1. Planning

   1. Inventory current SSIDs, VLANs, ACLs, DHCP scopes, and related components.

   2. Document existing authentication and segmentation policies.

   3. Define migration goals.

2. Lab testing and pilot roll-out

   1. Create a test SSID using Cloud RADIUS.

   2. Validate authentication across device types.

   3. Confirm VLAN assignment and fallback behavior.

   4. Enable monitoring mode.

   5. Start with early adopters.

   6. Monitor results in Devices and Alerts.

3. Staged deployment

   1. Expand migration gradually.

   2. Ensure certificates or AgentP are deployed.

   3. Whitelist MAC addresses if needed.

4. Validation

   1. Confirm RADIUS redundancy.

   2. Validate certificate workflows.

   3. Verify VLAN and policy assignments.

5. Legacy SSID retirement

   1. Disable old SSIDs after full coverage is confirmed.

   2. Ensure fallback VLAN exists.

6. Post-migration cleanup

   1. Disable monitoring mode.

   2. Remove obsolete SSIDs.

   3. Audit NAS devices.

   4. Update internal documentation.