A recent conversation with a NAC customer revealed a traditional type of reasoning that is sound enough and probably more common than you might think: nobody ever got fired for going with IBM (or Microsoft or Cisco or fill in the blank). But this has a twist.

The customer did a pretty thorough review of literature about NAC gear and divided it up into in-band and out-of-band appliances, endpoint software and infrastructure based.

He said he was too afraid of an in-band appliance because all traffic passed through it and could either be delayed or, if the box failed, blocked entirely. Never mind that these boxes can be built to have negligible delay and to fail open when they die. When he looked at a network diagram and saw it sitting in the middle of traffic, he got spooked.

When it came to software-based NAC he had an aversion to adding yet another client to endpoints. Than would mean more maintenance and it would also mean finding a stable endpoint configuration.

The company he worked for had a lot of mobile workers whose traffic was encrypted and had devices that sported updated management software. The risk of adding a NAC client is that it could destabilize the configuration and that possibility would arise each time the client was updated, which was another layer of possible trouble he didn’t want to enter into.

Hearing this you might figure he’d choose a clientless NAC product or one with a dissolvable, browser-based agent that relied on switches, firewalls, VPN concentrators or other infrastructure to enforce policies. And you’d be right.

And you might figure he’d choose a big vendor, but you’d be wrong. Rather he chose a NAC-only vendor who, he thought, had proved itself enough to trust the quality of the product. And, despite the economy, he thought they also might still be around in a couple of years if the product needs support.

Tim Greene is senior editor at Network World.