How to Configure 802.1x on Neat Devices

Last updated October 15, 2025

Contents

• Introduction — what is 802.1x?
• Requirements and limitations
  • Required components for configuration
  • Current limitations (at time of writing)
• Step 1. Setting up the devices
• Step 2. Verifying Neat device connectivity
• Step 3. Creating a Certificate Signing Request (CSR)
• Step 4. Signing the Certificate
• Step 5. Uploading the Certificate
  • For a wired 802.1x network
  • For a wireless 802.1x network
• Step 6. (Wired) Moving devices to an 802.1x network
• Additional information

Introduction — what is 802.1x?

802.1x is a standard network authentication protocol that enables port-based access control based on the user’s identity and its authentication by the organisation’s internal authenticator. This offers security within the network to protect organisations from unmanaged devices that find themselves in the workplace.

Requirements and limitations

Required components for configuration

• Neat devices must be on a local area network (LAN) (wired or wireless) and reachable by IP address for configuration, before moving devices to a wired 802.1x network environment.
• 802.1x capable switch and network
  • Wired: EAP-TLS only
  • Wireless: WEP, WPA, WPA2, EAP-TLS, EAP-PEAP
• Certificate Components for EAP-TLS :
  • Certificate Signing Request (CSR) 
  • Certificate Authority (CA) to sign CSR
    • Certificate Chains are supported
• Python 3 environment for customer-side script
  • Familiarity with Python and PIP is preferable
  • Install PIP – If you have Python version 3.4 or later, PIP is included by default
  • For the Latest version of neat-dot1x-cli please see the Release or run
    neat-dot1x-cli -V on your Command terminal.

Current limitations (at time of writing)

• Only EAP-TLS support for wired

---

Please note:

• The following steps assume that you have preconfigured 802.1x on your network including owning a certificate authority.

• The following process will need to be performed for each Neat device separately (e.g certificates will need to be requested, signed and uploaded separately for Neat Bar and Neat Pad).

---

Step 1. Setting up the devices

Accessing the device’s Web API can be done during the initial Out-of-Box (OOB) set-up, during the first installation/after a factory reset, or if they are already set up and running Microsoft Teams/Zoom, by enabling Remote Access instead.

1. Connect the devices to a LAN via ethernet or wifi that is NOT an 802.1x network. Please note that captive portals are not supported.
   • For an OOB configuration, confirm that the device is receiving an IP address by pressing the reset button on the back of the device. Please note: The device does not have to reach the internet – it only requires being reachable from a laptop/computer on the same network. The Web-API during OOB only applies up to choosing the platform to run (Microsoft Teams/Zoom).
   • For devices already running Microsoft Teams/Zoom room configuration, under Neat’s System settings navigate to System -> Remote access and enable. Please set a password, which is required for Steps 3 and 4. For more information on how to enable Remote access see the following article here.

---

Step 2. Verifying Neat device connectivity

1. From a laptop or computer on the same LAN, confirm that the Neat device is reachable:
   • Ping the IP address of the unit or
   • Ping via hostname (“Serial Number.local”) or FQDN

Tip: If the device is in OOB press and release the reset button on the back of the Neat device to see both the Serial number and the IP address.

If the Neat device is already running Microsoft Teams/Zoom go to System Settings > System > Network > Information > IP address.

---

Step 3. Creating a Certificate Signing Request (CSR)

1. Run the following command on your terminal/command prompt to PIP install the 802.1x client package:
   

   pip install neat_dot1x_client --upgrade --extra-index-url https://gitlab.com/api/v4/projects/41183007/packages/pypi/simple

   • Please note: Some networks will require a proxy to install the package and avoid SSL errors. Please use the--proxy http://<usr_name>:<password>@<proxyserver_name>:<port#> command accordingly.
     • Those with a transparent proxy, like Zscaler, may need to use the --trusted-host gitlab.com command.
   • Optional step: Verify version matches the latest as stated above by running:
     neat-dot1x-cli -V
     
     
2. Once the PIP package is installed, the command-line client, now called neat-dot1x-cli, should be available for use. In order to generate the certificate signing request (CSR), the following parameters are required to access the device’s Web-API:
   • IP address or Hostname
   • Username
     • a) Device in OOB => Username: oob
     • b) Device running Microsoft Teams/Zoom => Username: admin (Refer to Step 1) 
   • Password
     • a) Device in OOB => Password: Serial Number
     • b) Device running Microsoft Teams/Zoom => Password: Refer to Step 1
   • Optional arguments are supported in a JSON file format.
     
     {
"C": "NO",
"ST": "Oslo",
"L": "Oslo",
"O": "Neat",
"OU": "RD",
"CN": "802.1X device",
"EMAIL": "neat@neat.no"
}
     • Support for custom Subject Alternative Names (SAN) is available starting with firmware version 2025.3 and neat-dot1x-cli version 2025.6.23.
     • If you define a subjectAlternativeName, it is essential that this field contains either a dNSName (DNS Name), an iPAddress (IP Address), or both.
     • Note: All field names in the JSON configuration are case-sensitive.
       
       {
"C": "NO",
"ST": "Oslo",
"L": "EN",
"O": "Neat",
"OU": "ND",
"CN": "802.1X device",
"EMAIL": "neat@neat.no",
"subjectAlternativeName": {
"dNSNames": ["neat.no", "NA1234567890"],
"iPAddress": ["127.0.0.1"]
}
}
       
   • Please note; The "key": "value" pairs seen in the examples above are optional and their order is arbitrary. If a "commonName" is not provided, by default the device will use the Serial number instead.
     
     • If no key/value pairs are provided, the device will default to the following:
       

       {
         "country": "NO",
         "organizationName": "Neatframe Ltd",
         "organizationalUnit":"neat.no"
       }

       Important: Please note that Neat currently doesn’t support Subject Alternative Name (SAN) in the JSON file and therefore the CSR file that will be created will not have SAN field but only the Common Name.
3. Once you have decided on the arguments stated in point 2, run the following command substituting the arguments unique to the device and network:

   neat-dot1x-cli HOST_OR_IP USERNAME PASSWORD csr CSR_FILE.pem --subject-file Subject_JSON_File

   Please note: It could take up to 30 seconds for the device to generate the CSR
   
4. Optional step: To verify if the certificate signing request has been successfully created run: cat CSR_FILE.PEM and check if it opens a PEM-formatted text file which you will then need to be signed by your certificate authority (CA)

---

Step 4. Signing the Certificate

802.1x offers unprecedented visibility and secure, identity-based access control at the network edge. With EAP/TLS protocol each enterprise controls how they sign the certificate and typically own an internal Certificate Authority (CA) for this purpose.

1. Take the CSR created in Step 3 and sign the certificate using your own internal CA

Important Note: The certificate file will need to be in PEM format.

Tip: To reduce the frequency of updating the Certificate of each device we recommend setting up an extended expiry date. The certificate is saved as an encrypted file, stored in the device’s memory, and can only be wiped with a Factory reset.

---

Step 5. Uploading the Certificate

Once the CSR has been signed by the CA it can then be installed onto the device.

For a wired 802.1x network

neat-dot1x-cli HOST_OR_IP USERNAME PASSWORD init WIRED_CONFIG_JSON_PATH DEVICE_CERT_FILE.pem [SERVER_CA_CERT_FILE.pem]

• DEVICE_CERT_PATH This will be uniquely defined by each user and needs to be in PEM format. This will be inserted into the command line by replacing [DEVICE_CERT_PATH] with its unique file path.
  
  • If a certificate chain is used it will need to be a list of PEM-formatted certificates (all in the same file). For each following certificate in the chain, it must directly certify the one preceding it as is the standard protocol.
    
• SERVER_CA_CERT_PATH This is optional, but it’s required if the “caCertificate” property is not defined in the JSON configuration file.

Example of wired-config.json:

{
  "credentials": {
    "method": "TLS",
    "phase2Method": "NONE",
    "identity": "device-wired",
    "anonymousIdentity": "",
    "password": "",
    "altSubjectMatch": "DNS:myradius.server.local",
    "caCertificate": "-----BEGIN CERTIFICATE-----\n\n-----END CERTIFICATE-----\n"
  }
}

All fields are located within the credentials object.

• method (Required)
  • Description: Specifies the primary Extensible Authentication Protocol (EAP) method used for authentication.
  • Type: String
  • Allowed Values:
    • NONE: No EAP authentication is used.
    • PEAP: Protected Extensible Authentication Protocol. Requires a Phase 2 authentication method.
    • PWD: EAP-PWD (Password). A secure password-based authentication method.
    • TTLS: Tunneled Transport Layer Security. Requires a Phase 2 authentication method.
    • TLS: EAP-Transport Layer Security. Uses client-side certificates for authentication.
• phase2Method (Required)
  • Description: Specifies the inner authentication protocol used inside the secure tunnel created by methods like PEAP or TTLS.
  • Type: String
  • Allowed Values:
    • NONE: No Phase 2 method is used. This is required when method is TLS or PWD.
    • PAP: Password Authentication Protocol (sent in cleartext within the tunnel).
    • MSCHAP: Microsoft Challenge-Handshake Authentication Protocol.
    • MSCHAPV2: Microsoft Challenge-Handshake Authentication Protocol version 2.
• identity (Required)
  • Description: The username or identity for the EAP authentication. For EAP-TLS, this often corresponds to the Common Name (CN) or Subject Alternative Name (SAN) in the client certificate.
  • Type: String
• anonymousIdentity (Optional)
  • Description: An outer identity used to hide the user’s true identity during the initial phases of EAP authentication. This is primarily used with PEAP and TTLS.
  • Type: String
  • Default: Empty string ""
• password (Optional)
  • Description: The user’s password. This is required for EAP methods that rely on passwords, such as PEAP, TTLS, and PWD.
  • Type: String
  • Default: Empty string ""
• altSubjectMatch (Optional)
  • Description: Used to verify the identity of the RADIUS authentication server. The client checks if the server’s certificate contains this Subject Alternative Name (SAN).
  • Type: String
  • Format: DNS:<hostname> or IP:127.0.0.1
  • Example: "DNS:myradius.server.lcal"
• caCertificate (Optional)
  • Description: The Certificate Authority (CA) certificate used to validate the RADIUS server’s certificate. The certificate must be in PEM format (Base64 ASCII encoded). Include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers.
  • Type: String

For a wireless 802.1x network

neat-dot1x-cli HOST_OR_IP USERNAME PASSWORD init_wifi WIFI_CONFIG_JSON_PATH [DEVICE_CERT_PATH] [CA_CERT_PATH]

• DEVICE_CERT_PATH This will be uniquely defined by each user and needs to be in PEM format. This will be inserted into the command line by replacing [DEVICE_CERT_PATH] with its unique file path.
  • If a certificate chain is used it will need to be a list of PEM-formatted certificates (all in the same file). For each following certificate in the chain, it must directly certify the one preceding it as is the standard protocol.
• SERVER_CA_CERT_PATH This is optional, but it’s required if the “caCertificate” property is not defined in the JSON configuration file.

Example of WiFi-config.json:

{
  "ssid": "802.1x",
  "isHidden": false,
  "wifiSecurity": "EAP",
  "credentials": {
    "method": "TLS",
    "phase2Method": "NONE",
    "identity": "device-wifi",
    "anonymousIdentity": "",
    "password": "",
    "altSubjectMatch": "DNS:myradius.server.local",
    "caCertificate": "-----BEGIN CERTIFICATE-----\n\n-----END CERTIFICATE-----\n"
  }
}

These fields define the basic properties of the Wi-Fi network.

• ssid (Required)
  • Description: The Service Set Identifier, which is the public name of the Wi-Fi network. 📶
  • Type: String
• isHidden (Optional)
  • Description: Specifies whether the network’s SSID is broadcasted. Set to true if the network is hidden.
  • Type: Boolean
  • Default: false
• wifiSecurity (Required)
  • Description: The security protocol used by the Wi-Fi network. The required fields within the credentials object depend on the value selected here.
  • Type: String
  • Allowed Values:
    • NONE: An open, unsecured network. No credentials are needed.
    • WEP: Wired Equivalent Privacy. Requires a password (WEP key).
    • WPA: Wi-Fi Protected Access. Requires a password (passphrase).
    • WPA2: Wi-Fi Protected Access II. Requires a password (passphrase). This is the standard for personal security (WPA2-Personal).
    • EAP: Extensible Authentication Protocol (802.1X). Used for enterprise networks. This requires the full set of EAP fields within the credentials object.
• credentials (Required)
  • Description: An object containing the authentication details for the network. The fields required inside this object are determined by the wifiSecurity setting.
    —-
  • method
    • Description: The primary EAP method used for authentication.
    • Required when wifiSecurity is EAP.
    • Type: String
    • Allowed Values: NONE, PEAP, PWD, TTLS, TLS.
  • phase2Method
    • Description: The inner authentication protocol for tunneled EAP methods (PEAP, TTLS). Required when wifiSecurity is EAP.
    • Type: String
    • Allowed Values: NONE, PAP, MSCHAP, MSCHAPV2
  • identity
    • Description: The username or identity for EAP authentication.
    • Required when wifiSecurity is EAP.
    • Type: String
  • anonymousIdentity
    • Description: An outer identity used to hide the user’s true identity during the initial EAP exchange.
    • Type: String
  • password
    • Description: This field serves two purposes:
      • 1. For WPA/WPA2/WEP: It holds the network’s passphrase (Pre-Shared Key)
      • 2. For password-based EAP methods (PEAP, TTLS, PWD): It holds the user’s password.
    • Type: String
  • altSubjectMatch (Required for EAP)
    • Description: Used to verify the identity of the RADIUS authentication server by matching a value in the server certificate’s Subject Alternative Name (SAN).
    • Type: String
    • Format: DNS:<hostname> or IP:<IP>
    • Example: "DNS:myradius.server.local" and/or ”IP:127.0.0.1”
  • caCertificate (Required for EAP)
    • Description: The Certificate Authority (CA) certificate used to validate the RADIUS server’s certificate. The certificate must be in PEM format.
    • Type: String

neat-dot1x-cli HOST_OR_IP USERNAME PASSWORD init_wifi WIFI_CONFIG_JSON_PATH [DEVICE_CERT_PATH] [CA_CERT_PATH]

---

Step 6. (Wired) Moving devices to an 802.1x network

Finally, move the device to a wired 802.1x network and the device will begin to answer the challenges of the 802.1x authenticator. As soon as the identity of the device is known, all traffic from that endpoint is allowed and your device will now be connected to your network!

Additional information

The Python tool syntax:

Tool version: neat-dot1x-cli -V
Help: neat-dot1x-cli -h
Positional arguments help for CSR parameters: neat-dot1x-cli X Y Z csr -h
Positional arguments help for Uploading cert (wired): neat-dot1x-cli X Y Z init -h
Positional arguments help for Uploading cert (wireless): neat-dot1x-cli X Y Z init_wifi -h

---

If you have any questions or encounter issues with the steps above, please reach out to Neat Support at support@neat.no.