(via infosecramblings) Jennifer over at Security Uncorked has posted up a paper on why NAC is failing. It makes for a good read (pdf).
If you were to ask me before reading this paper what my gut reaction to NAC is, it would read:

• complex to manage in anything beyond a lab or small org with strict system policies, low speed of change, and few exceptions.
• can only exist with other foundational technologies like something to compare against (AV version, etc) and something to control access (managed switches, firewalls, proxy, etc). If you don’t have the foundations managed well, you have no business putting NAC in yet.
• can be a nice way to validate inventory and policies, every organization still has to manage the exceptions and guests. If you have inventory and policy-checking already being done, NAC’s only purpose is rogue isolation which you can do, to varying degrees of depth, in many other (even homebrew) ways.
• I always hear about messy, issue-prone installation attempts and have never heard of one real success story.
• orgs like McAfee already are trying to put all the pieces together anyway; it’s not a big step to take their huge suite of apps and just add in a control piece to their rogue detection/ePO/HIPS/NIPS conglomerate (for better or worse, since all of that rolled into one huge dungpile makes for a beast in administrative costs). But you still need the foundations set even outside such a “complete” (yay marketing!) security suite. This leads into the “it’s a feature not a product” argument which I don’t usually voice because it sounds way to “analyst-like” for my tastes. Besides, too many features = unwieldy product that is worth far less than the sum of the features!

It makes me a lot more confident in my impressions of NAC that Jennifer hit on these points and more (for instance I totally didn’t think about authenication/identity with NAC) in her paper. I’m also not sure I’ve ever read a more complete and understandable description of NAC in general!

One key quote I want to pull out is this one, which I think succinctly sums up some of my feeling.

A single NAC product will not, in any environment, scale or grow to a level
acceptable for widespread adoption. At the moment, the solutions are too difficult to implement and there are other alternatives that give organizations many of the features NAC can offer without the hassle involved with implementing NAC.

Often we do have to implement security technologies and apps that aren’t perfect and don’t provide 100% coverage no matter how much hacking we do on the side. But NAC is too big of a beast for many managers to swallow and still admit it only protects swaths X, Y,and Z systems/scenarios. Huge suites of varying quality (like McAfee, Symantec, Cisco, etc) that already have roots in what I consider the foundational aspects of an enterprise network already have their work cut out for them. It’s natural the NAC will absorb into them rather than be yet another boulder to massage into the corporate cyber landscape.

If I had one suggestion, it would be to include a sub-list in the exec summary under the technical challenges item, and quickly list the big technical challenges specifically, or word it in a way that my initial reaction to that item is not the question, “What challenges?”