Windows XP Service Pack 3 is coming on April 29, which means NAP will be coming to an OS near you. Already, Hewlett-Packard has announced it will integrate network access protection with its ProCurve identity driven management product, which provides identity-based management to network access. We can expect more vendors to follow suit.

The two main components of the NAP agent are the enforcement client which enforces access control using host to host IPSec, 802.1X, DHCP, or a VPN (remote access), and a System Health Agent (SHA) which reports system health to the NAP client. SHA's are built by software vendors that want to communicate their status to the NAP agent. For example, an antivirus vendor develops a SHA that interacts with the NAP agent reporting on the AV status and responding to queries. Pairing a NAP Policy Server in Windows Server 2008 and various health servers -- servers that can validate the status information provided by their SHA -- a full NAC system for Windows computers can be deployed. Avenda Systems even has a NAP agent for a few Linux distributions like CentOS, Fedora Core, and SUSE.

Microsoft's NAP client on Windows XP and Vista doesn't necessarily get you universal host assessment. The SHA's that report on the status of software running on the target computer have to be developed and deployed before reporting can begin. I expect that would become a requirement for any security product destined for the Windows OS, but as vendors like to say, when there is demand, we will build it.

A number of NAC vendors have privately indicated that they want out of the agent game and have been waiting for NAP agents for Windows XP to ship so they can leverage it rather than maintain their own agents. While using libraries and SDK like OPSWAT reduces development time, they still have to push an agent out to a host. Without the correct user permissions, like local Administrator rights, agents won't run properly.

In addition, having a SHA from a particular vendor isn't enough. Guest computers can report on the health of their endpoints, but unless you have a corresponding Health Requirement Server, a system that can validate a program's health status, such as AV software version, configuration, and signature timestamp, the SHA can't be assessed. A Health Requirement Server needs to know how to interpret a SHA.

There are still plenty of components that need to be in place before a product can take off. Microsoft has provided a framework for NAP, but software and hardware vendors need to fill in the SHA and Health Requirement Servers to fill in the gaps. Since Microsoft is the desktop OS, it's not much of a stretch to guess other vendors will integrate, and its NAP partner program boasts a huge number of vendor partners. It's just a matter of time, now.