Part II of the Clearing Up 802.1X Series
Securing Multiple Device Authentication on 802.1X

VLANs and Multiple Device Authentication
I always say the road to insecurity is paved with good intentions, and implementations of 802.1X are some of the best examples. I find folks tend to be so excited if-and-when they get 802.1X working, that they don’t bother to put it through the ringer and see what’s actually happening on the switch once it’s working.

When implementing multiple device authentication on a single port with 802.1X, there are *lots* of considerations, but one major one I see from a security perspective.

I’m giving an example of issues and best practices with multiple device authentication using a VoIP scenario because it’s the most common use of multi auth, and probably the single largest vulnerability point because of accessibility to phones in an organization.

A VoIP Example
Let’s imagine a VoIP phone with the standard PC data pass-thru on the back… most VoIP phones have this and it’s the best way to make use of data drops when you have a converged network.


*click image to enlarge

If you’re reading this blog, you should immediately know what this means. If not, I’ll try to talk it through. In enterprise environments with VoIP, we use a protocol called LLDP-MED and/or DHCP scopes to tell VoIP phones where they should be on the network, and let the infrastructure identify them as phones.

So, a phone will hop on the network, get it’s DHCP information and then be told to go to it’s Voice VLAN (let’s say VLAN 200 is Voice). During this process, the phone is actually communicating initially on the default Data VLAN  (let’s say VLAN 1) to get the scope information.

In this configuration, the Switch Port (shown above) will be untagged for the Data VLAN 1 and tagged for the Voice VLAN 200, to allow the phone and PC to access the data network and then the phone to access it’s Voice network.

The Issue
With an 802.1X-enabled port, the phone will actually authenticate (however it does that, either Mac-auth or 802.1X) on VLAN 1 (our default data VLAN)… then once it receives its scope parameters, it will move to VLAN 200.

On most switches, when it does this, it leaves VLAN 1 ‘open’ and authenticated. So, it would be easy for a malicious user or guest to easily access our data VLAN from anywhere they can find a phone, even though we have port security turned on.

The Resolution
There are a couple of solutions here, but they all require planning and perhaps a bit of ‘creative’ routing or network segregation.

1. One resolution is to create a trash or ‘black hole’ VLAN as I call it. This would be a VLAN to nowhere… and that would be the configured default untagged VLAN on the switch ports (either all of them, or the ones exposed to this environment).

If you go this route, there are a couple of things to address- you’ll need to create a path for your phones to be able to access their DHCP server so they can receive scope info and get on the appropriate VLAN to operate. You also have to think about your migration path from an unauthenticated to authenticated network. Generally we recommend customers moving to 1X to use null VLAN assignments to activate whatever current VLAN is untagged on the port (to accommodate current network design). If the port is untagged for a black hole VLAN, you’ll need to actually push ‘real’ authenticated VLAN assignments down (from RADIUS or your NAC solution) for every user.

2. A Second idea would be to use either the guest VLAN or a quarantine VLAN as the default untagged VLAN on the edge ports. This would give some immediate but limited connectivity.

Again here, we have a few issues. Currently, most switches do not support unauthenticated devices and authenticated devices on the same port, meaning the guests would have to be *somehow* authenticated- perhaps with Web-auth on a true Guest VLAN (versus the 1X-specified ‘unauth’ VLAN). (There are also some tricky things you can do with a good RADIUS server to get around this.)

If you think this sounds a little confusing- you’re right. There are lots of terms in 1X that may ‘seem’ to intuitively mean one thing but have a very specific meaning within the confines of 1X. The unauth-VLAN is one of those terms.

And, of course, with a quarantine or guest VLAN we have the same requirement to allow the phones access to resources they may need.

The Conclusion
Multiple device authentication can be tricky to secure, but it’s certainly possible with the current 802.1X version. I always suggest beating the ever-loving crap out of 1X configurations in a lab before deploying. Try things, allow authentication, the use your switch ‘show’ commands to watch the port behaviour and see what’s actually authenticating, what’s ‘open’ and what residual effects may cause issues in security.

The Future
Of course, the ease of multi-device authentication and the security of it all will greatly increase with the 802.1X-REV. I certainly don’t want to dimish the importance of the new 1X revision- the MACSEc (802.1AE) and key exchange (802.1af) rolled into the revision will bring about great new horizons!

# # #


Author, speaker, and recognized authority on network and wireless security architectures, Jennifer (JJ) Minella helps organizations solve technical problems and align teams.

View all posts


  • I’m not sure the place you are getting your information, however great topic. I must spend some time learning more or understanding more. Thank you for magnificent information I was in search of this info for my mission.

  • I have the same problem. Did you find any solution about the application of the 802.1x standard on a trunk port?

  • Currently I have voip phones setup on trunk port to accomodate the voip vlan as well as pc vlan. If I want to implement 8021x on these ports with:

    the voip phone keeping its current vlan
    an authorzied pc pulling its vlan from RADIUS.
    as well as UNauthorized pc’s being dumped into the guest/failed-auth vlan

    How would this be configured with best practice? The fact that (to my knowledge) 8021x doesn’t support trunk ports has been the main hurdle that I am facing…

  • Hi Mike!
    It depends on the customer and their security requirements. Generally, a best practice in a wired 802.1X environment would be to put the edge ports in an untagged (access mode) membership of a ‘trash’ or ‘guest’ VLAN.

    Now, that’s not a practical solution for all customers, since some may have location-based VLANs and don’t want to push down VLAN assignments from the RADIUS server, but in most cases and in networks with high security requirements this is definitely a best practice.

    The phone would operate on the tagged membership of it’s assigned VLAN, ie VLAN 20, while the PC would use untagged trash VLAN (let’s say 99). Once the PC authenticated, we could push down the real data VLAN (maybe 1) and everything would go swimmingly.


  • I’ve always thought of these Cisco VoIP phones used in office environments, but what about call centers? I know many companies that would like to remove their call centers from scope of regulatory compliance, but they have that nasty data port that could be used for evil. Do you find most companies VLAN off their voice from their data? I’ve heard for TOS purposes many companies do not do this. If so, what’s there to keep a hacker from using one or the other to access sensitive systems on the data network?