What Comply-to-Connect actually asks for

Comply-to-Connect gets described as a technology, which leads people to look for the product that satisfies it. There isn’t one. C2C is a set of capabilities a component has to be able to demonstrate, and most of the difficulty is in integration and process rather than in any single tool.

Here is the shape of it, and where the work usually stops.

The capabilities, in sequence

Discovery. Know what is connected. Not what the asset register says — what is actually present, including the equipment procured outside the normal channel and the systems inherited from a programme that ended years ago.

Identification. Establish what each device is. Discovery gives you an address and a MAC; identification gives you a device class, and with it an expectation of how that device should behave and what it should be permitted to do.

Compliance assessment. Determine whether the device meets policy — patch level, agent presence, configuration state. This is where integration with existing tooling stops being optional. The compliance signal already exists in SCCM, ACAS, EPO or MDE. Rebuilding it inside the access control platform creates a second source of truth that will diverge.

Remediation. Do something about non-compliant devices. Quarantine, redirect, restrict, or push the update. This is the first step with a real user impact, and it is where deployments tend to slow down.

Continuous monitoring. Keep assessing after admission. A device compliant at 9am and compromised at 11am should not retain its authorisation because it passed once.

Where components stall

Between identification and compliance assessment. Discovery and identification are largely technical and can be completed by a capable team with the right platform. Compliance assessment requires the access control platform to consume authoritative data from systems owned by other teams, on their schedule, in their format. That is an organisational integration problem wearing a technical costume.

At remediation, for the reason every NAC project stalls. Remediation means denying something, and denying something means a user or a mission system is affected. Without a staged plan and a tested rollback, this step gets deferred — and a C2C effort that discovers, identifies and assesses but never remediates is a monitoring project.

The practical advice

Inventory the compliance signals you already have before designing anything. ACAS is already scanning. SCCM or MDE already knows patch state. The integration design should start from what those systems can authoritatively supply, because that determines what your policy can actually evaluate.

Decide the device classes that cannot comply, early. Every component has equipment that cannot run an agent and cannot be patched on a normal cycle — often the equipment doing the mission. Those classes need a designed authorisation path, not an exception granted under pressure during rollout.

Treat remediation as a change programme, not a configuration. Staged, reversible, with the service desk briefed. The technical work of enabling quarantine is small. The work of enabling it without disrupting operations is the actual engagement.

Write the evidence as you go. The assessor will ask how each capability is satisfied and what demonstrates it. Documentation assembled afterwards from memory is both worse and more expensive than documentation produced as a deliverable at each step.

Why this is a specialist job

C2C sits across network engineering, endpoint management, vulnerability management, and the policy authority to decide what gets denied. Very few people have worked across all four in a DoD context, which is precisely why the capability is scarce — and why an integrator who has only done commercial NAC tends to underestimate the integration surface.