Showing results for 
Search instead for 
Did you mean: 


Cisco Employee
Cisco Employee

Securing devices without 802.1X


PSK (Pre-Shared-Key) WLAN is widely used for consumer & enterprise IoT onboarding as most of IoT device doesn’t support 802.1X. While PSK WLAN provides an easy way to onboard IoT, it also introduces challenges as it doesn’t provide the security that many enterprises require due to the limitation of a single PSK for the entire WLAN.

PSK Pros: -

All devices receive the same pre-shared key to connect to a wireless access point. The benefit of using this method is that it's very simple for the end-user to use. There's one password to remember, and all devices use it to connect to the wireless. It's easy and requires no further back-end infrastructure.

PSK Cons: -

Because each device uses only one password, there's no ability to uniquely identify devices, or the users using them. It is not possible to apply unique policies to these traffic streams. For example, there's no ability to assign different VLAN, Quality of Service (QoS), and other policies.

This creates additional workload and overhead as far as support is concerned. There are also security concerns as if this one password is compromised, unfettered access across the wireless network is theoretically possible.


A better way to Secure your PSK Network; iPSK:

Identity PSK provides a way to assign users and devices unique keys, build identity-based groups, and scale them across the network. For example, a hospital might have wireless infusion pumps and patient monitoring tools for which they would like to apply different group policies or an IT admin at a manufacturing plant will segment barcode scanners and sensors into different groups.

Devices and smartphones will connect to one SSID yet have different security policies. IPSK on Cisco wireless solution is a great feature to address security for IoT and BYOD.





Configuring IPSK:

Cisco provides an easy way to configure iPSK. Couple of clicks in the Wireless SSID configuration and a simple authorization profile in the ISE. IPSK can be configured on any AAA server that supports Cisco AV-PAIR.


Other benefits with iPSK:

In Cisco WLC, the network admin can define a Local Policy and assign various network Service Profiles & Securities like ACL, AVC, mDNS, or Umbrella Profile into a new local policy.

Likewise, IPSK also can be combined with Local policies on the controller and mapped to a specific WLAN. Along with PSK Mode and Password, the AAA Server such as ISE can return a Role for a particular user for better segregation of Service Profiles and Security.

Each local policy can be configured with a different profile name, ACL, Role, Device Type and even Active Hours based on the AAA override to restrict/permit the policy from being able to use/deny the services not allowed by the profile on the same WLAN.

When combining IPSK and Local Policies on the same WLAN the use cases can be unlimited and open to many different deployment scenarios.


The Main Challenge:

Generally, in a high-scale environment, using iPSK brings in challenges or rather additional human intervention while feeding in PSKs for each user or group in ISE. The main way to leverage IPSK in scale was to extend ISE internal DB to include IPSK value. While this is a good way to leverage IPSK, it required ISE admin to maintain IPSK to Device MAC address mapping for the entire deployment.

Here I am going to introduce a better way to use IPSK by utilizing an external portal + SQL endpoint database for IPSK management, called iPSK Manager. The iPSK Manager portal can be used by end-user to register devices on their own as well as manage IPSK string without the help of ISE admin.

There are three main use cases the iPSK Manager portal supports:

  1. iPSK IoT portal
  2. iPSK Personal portal
  3. PSK Assisted Onboarding

For More Information on this, refer:


Who will say NO to additional Security?

iPSK feature can be enhanced with additional capabilities which can be very useful for allowing users to do BYOD that can talk amongst themselves (e.g. wireless printer) without exposing devices to other users.

Another example, this would allow your medical pumps to have their correct access while allowing an HVAC controller on the same SSID restricted from communicating with your medical systems. The further expansion of segmentation closer to the end device itself helps further minimize the chances of you becoming the next Target data breach.

Here, the customers can prevent Client or IoT devices with different or same PSK keys on the same or different WLAN from talking to each other or bridging, in other words, configure peer-to-peer (P2P) blocking or bridging.

Guess what, Cisco provides this facility by a single click in the SSID. This also brings in more flexibility on how to have the deployment by providing options like completely drop the traffic b/w clients or allow traffic of the same Private Group and a lot.



Yet Another PSK Variation - MPSK:

Cisco provides another option for deployments where there are infrastructure limitations, where customers cannot afford an ISE or AAA in their network. That is MPSK.

MPSK feature supports multiple PSKs simultaneously on a single SSID. This feature provides us an option to uniquely identify devices or users, unlike traditional PSK solution. Imagine a situation of adding a new set of team members in an organisation, this option eliminates re-using the existing PSK which can be a security treat, instead add a new PSK for the new group.

Cisco allows users to configure 5 PSKs per SSID. You can use any of the configured PSKs to join the network and WLC authenticates the clients here. This is different from the Identity PSK (iPSK), wherein unique PSKs are created for individuals or groups of users on the same SSID. Each SSID can support up to 5 PSKs. This can be expanded too.



Network administrators are dealing with an explosion of IoT devices from surveillance cameras and environmental sensors to medical devices to smart shelves. This will bring in lots of opportunities to innovate more and drive expansion in handling PSK based devices for Better Usability, Security, and in handling scale.

Signing Off!!!




1 Comment

Thanks for laying this out.  I have an environment very much like the one you describe with lots of medical devices, old and new, connecting to our network.  I find iPSK very useful.  iPSK is also handy in the event that one of the PSKs becomes compromised.  It allows us to change the PSK for a much smaller group of endpoints!


One thing I haven't figured out is how to apply policy strictly based on the PSK value - in other words, I'd like to try to authenticate a device based on the PSK value.  Now, I have to profile or identify the device by MAC and then provide the appropriate PSK in the authorization profile.  What I'd like is to use the PSK value to identify the device and then add it to the appropriate endpoint group.  This seems to be the reverse of what happens now.  Any thoughts on this?

Content for Community-Ad