I keep hearing about NAC as both standalone appliances and as part of switching infrastructure. Which is the best way to buy this technology?

The short and annoying answer is, of course, "it depends."

You've keyed in on a critical trend, which is that ultimately NAC belongs in the infrastructure and will be a "feature" of a LAN switch. That said, NAC as an appliance makes perfect sense for a lot of deployments and won't be obsolete for a long time.

The true question becomes, what kind of NAC should you invest in now that will provide sustaining value to your enterprise for years to come? In reality, the answer probably has more to do with the capabilities of the NAC system than its form factor. We'll first talk about which form makes sense in which deployments and then talk about the sustainable feature set.

NAC as an appliance is the ideal answer if you've recently upgraded your LAN access switches. Self-contained, standalone appliances provide the simplest deployment model for incorporating strong access control features directly into your LAN.

NAC as a switch makes sense if you have plans to upgrade your LAN switches anytime in the next year. Ensure that you're getting all the switching features you need - like Power over Ethernet - to support other key LAN projects, but the combination of switch and NAC provides good value since you'll only have to buy one device instead of two.

If a switch upgrade isn't imminent, but you're interested in migrating toward switches that can provide the NAC functionality, look for a vendor that offers both switches and appliances - and evaluate them both. That way, you could start a deployment with appliances now and migrate to switches in the future without any changes to your policy creation and distribution or anything else.

Ultimately, your question comes down to investment protection, and to do that well, you need to focus on the NAC platform's feature set. You need to ensure you can use those features to solve your current NAC problems - perhaps you only need to segment guests and some contractors today - but you also must be able to extend the configuration of the system to support a broader set of policies in the future. For example, your company might want to segment within your employee base so that only finance workers can reach finance servers. Or you might want to control application use in more detail, for example by preventing guests from running IM or by limiting access to resources by location or time of day by, for instance, denying use of a customer banking application after bank hours are over.