Comply-to-Connect (C2C): Device Posture Before Access

First developed as part of our LinkedIn content series, June 2026. Expanded and updated for this site.

An unpatched laptop connects to a DoD network segment housing CUI. Without Comply-to-Connect, it gets a valid IP address and full network access in under three seconds. With C2C, it gets quarantined to a remediation VLAN before the user finishes entering their credentials.

That distinction -- three seconds of unchecked access versus zero seconds -- is the entire value proposition of device posture enforcement at the network edge. And it is why C2C sits at the foundation of the DoD Zero Trust Strategy, not as an optional add-on, but as a prerequisite for everything else in the stack.

Why C2C Matters Now

Three forces converged to make Comply-to-Connect non-negotiable:

The DoD Zero Trust Strategy (2022) names device posture validation as a foundational capability across all seven pillars. You cannot claim Zero Trust maturity without proving that unhealthy devices cannot reach protected resources. C2C is how you prove it.

CISA's Zero Trust Maturity Model places device health checks at the "Advanced" tier -- meaning federal agencies pursuing ZTA cannot skip network admission controls and claim they are on track. Device trust is not a nice-to-have; it is a gate.

Colonial Pipeline (2021) demonstrated what happens without device-level admission control. Attackers used a single compromised VPN credential -- on an account with no multi-factor authentication -- to enter the corporate IT network, and the company shut down pipeline operations because it could not be confident the intrusion would stay contained to IT and out of operational technology. There was no posture check at admission. There was no quarantine for the connecting endpoint. There was no continuous reassessment to detect abnormal behavior after it connected. The pipeline shut down for days, fuel shortages hit the Eastern Seaboard, and the root cause was simple: a connection that should never have had that access was never asked to prove it deserved it.

What C2C Is and Is Not

Comply-to-Connect is a network admission control discipline that evaluates a device's security posture before granting access and continuously re-evaluates that posture throughout the session.

Here is the contrarian take worth stating directly: NAC has been "dead" according to analysts for a decade, yet C2C is the most operationally impactful Zero Trust control the DoD has deployed. Turns out checking whether a device deserves network access before granting it was never obsolete -- it just needed better data. The old NAC deployments failed because they checked a certificate and called it done. C2C checks patches, STIG compliance, EDR status, disk encryption, firewall state, configuration baselines, software inventory, and certificate validity -- then keeps checking every hour for the life of the session.

What C2C is not:

Not a firewall replacement. C2C decides whether a device gets on the network at all. Microsegmentation and firewalls decide what the device can reach once admitted.
Not user authentication. Phishing-resistant MFA and CAC/PIV verify the human. C2C verifies the machine independently.
Not a one-time gate. Legacy NAC checked posture at connection and never looked again. C2C reassesses continuously -- a device that drifts out of compliance mid-session gets re-quarantined.
Not endpoint management. SCCM, Intune, and MDM push configurations. C2C verifies those configurations actually took effect.

The DoD C2C Program: Five-Step Flow

The Department of Defense C2C program, directed by Congress in the FY2017 NDAA and managed by DISA, defines a five-step lifecycle that every device traverses on every network connection:

Step 1: Identify

The device presents a machine identity -- typically a DoD-issued machine certificate stored in the TPM. The infrastructure records the device type, hardware fingerprint, and organizational affiliation. Unknown devices that cannot present valid machine identity are blocked outright or shunted to a guest network with no access to mission resources.

Step 2: Authenticate

The device identity is verified against the authoritative directory (Active Directory, or the DoD's enterprise PKI chain). Authentication confirms the device is what it claims to be, not just that it possesses a certificate. Revoked, expired, or mismatched identities fail here.

Step 3: Assess

This is where C2C earns its name. The infrastructure queries the device for posture data and evaluates it against the compliance policy:

Criteria	What It Checks	Typical Requirement
OS patch level	Missing security updates	Critical patches applied within 30 days
Endpoint protection	EDR/AV status and signature currency	Active agent, definitions current within 24 hours
Disk encryption	Full-disk encryption enabled	BitLocker (Windows), FileVault (macOS), LUKS (Linux)
Host firewall	Firewall enabled and configured per baseline	Enabled with organization-approved ruleset
STIG compliance	Configuration hardening score	No CAT I findings, CAT II findings below threshold
Certificate status	Machine certificate validity and chain	Valid, not expired, not revoked, correct issuing CA
Software inventory	Prohibited/unauthorized software absent	No blacklisted applications present
Mobile device posture	MDM enrollment and policy compliance	Enrolled, not jailbroken, encryption enabled

Step 4: Authorize

Based on the posture assessment result, the infrastructure makes an admission decision:

Compliant: Full access to the authorized network segment. The device's trust score meets or exceeds the threshold for the requested resource sensitivity level.
Partially compliant: Limited access. The device may reach low-sensitivity resources but is blocked from CUI enclaves or classified segments. Typical scenario: missing one non-critical patch but otherwise healthy.
Non-compliant: Quarantine. The device lands on a remediation VLAN with access only to patch servers, update repositories, and the self-service remediation portal. No production access.
Unknown/Unmanaged: Block. The device cannot present valid machine identity or the posture agent is absent. It receives no network connectivity beyond a captive portal explaining how to enroll.

Step 5: Monitor

Admission is not the end. The infrastructure continuously reassesses device posture throughout the session. If a device drifts -- an endpoint protection agent stops reporting, a prohibited application is installed, a patch-level check fails on the next cycle -- the device is dynamically re-quarantined. The user gets a notification; the SOC gets a telemetry event.

Continuous Reassessment

The "continuous" in continuous reassessment is not marketing language. In a mature C2C deployment, reassessment happens at multiple intervals:

Real-time event triggers: Endpoint agent detects a posture change (AV disabled, unauthorized process started) and immediately signals the NAC infrastructure. Re-evaluation fires within seconds.
Periodic full posture scans: Every 1-4 hours, the infrastructure performs a complete posture assessment identical to the initial admission check. Devices that passed at 08:00 but missed a noon patch deadline get re-quarantined at the 13:00 scan.
Network behavior anomaly detection: Even if posture data looks clean, behavioral signals (unusual port scanning, lateral movement attempts, C2 beaconing patterns) can trigger a forced reassessment or immediate quarantine.
Incident-driven lockdown: When the SOC declares an incident, all devices on the affected segment can be forced through an immediate full reassessment. Devices that fail are quarantined; devices that pass remain operational. This is surgical, not a network-wide outage.

The Colonial Pipeline failure was partly a monitoring failure. Even if the initial VPN access had been legitimate, a continuous monitoring system watching device behavior post-connection would have flagged the lateral movement within minutes, not days.

Implementation Approaches

802.1X-Based (Port-Level Enforcement)

IEEE 802.1X provides port-based network access control at Layer 2. The device authenticates to the network switch using EAP (Extensible Authentication Protocol), typically with machine certificates. The RADIUS server evaluates authentication and queries posture before instructing the switch to assign a VLAN.

Strengths: Enforcement happens at the physical or wireless port -- the device literally cannot send traffic until authorized. Widely supported on enterprise switches and wireless controllers. Mature protocol with decades of deployment history.

Limitations: Wired 802.1X requires switch configuration on every port. Legacy devices (printers, IoT, medical equipment) often lack supplicant support. VPN connections bypass the switch entirely and need a separate enforcement point.

Agent-Based (Deep Posture Visibility)

A lightweight agent on the endpoint continuously collects posture telemetry -- patch state, running processes, configuration compliance, certificate health -- and reports to the C2C infrastructure. The infrastructure evaluates the telemetry against policy and instructs the network layer on admission decisions.

Strengths: Deepest posture visibility. Can assess application-layer compliance (specific registry keys, file permissions, STIG checks). Enables real-time re-evaluation without waiting for the next network-layer scan.

Limitations: Requires agent deployment and maintenance on every managed device. Does not cover unmanaged or BYOD devices. Agent health itself becomes a posture criterion (is the agent running? is it the current version?).

Agentless (Network-Based Discovery)

Passive network monitoring, active scanning, and integration with existing management platforms (SCCM, MDM, vulnerability scanners) assess posture without requiring software on every endpoint. The C2C infrastructure correlates data from multiple sources to build a posture picture.

Strengths: Covers unmanaged and IoT devices that cannot run agents. No endpoint software dependency. Lower deployment friction.

Limitations: Less granular than agent-based assessment. Posture data may be stale (depends on scan frequency). Cannot enforce in real-time on the endpoint itself.

Hybrid (The Realistic Deployment)

Most production C2C deployments use all three: 802.1X for managed endpoints with agents providing deep telemetry, agentless discovery for IoT and unmanaged devices, and all three feeding a unified policy engine that makes consistent admission decisions regardless of device type.

Relationship to Other Zero Trust Controls

C2C does not operate in isolation. It occupies the device trust pillar within a broader Zero Trust Architecture that includes:

Phishing-resistant MFA verifies the user. C2C verifies the device. These are independent checks -- a valid user on a compromised device still gets quarantined, and a healthy device with stolen credentials still fails authentication.

Microsegmentation limits lateral movement for devices that pass admission. C2C decides whether a device gets onto the network; microsegmentation decides which specific workloads the admitted device can reach. Defense in depth: even if C2C admits a subtly compromised device, microsegmentation constrains the blast radius.

Identity governance manages the lifecycle of access entitlements. C2C enforces device health at the moment of access. Together, they ensure that only authorized users on healthy devices can reach only the resources their role requires.

STIG compliance automation hardens device configurations. C2C verifies those configurations are actually in place at connection time. Without C2C, a device can drift from its hardened baseline and retain full access indefinitely.

Patch management remediates vulnerabilities. C2C enforces patch compliance as a condition of network access. This creates genuine urgency for patching -- users cannot work until their device is current. That enforcement loop is more effective than any patching SLA.

Key Takeaways

C2C checks device posture before network admission and continuously thereafter -- not just at login

The DoD five-step flow (Identify, Authenticate, Assess, Authorize, Monitor) applies to every device on every connection

Quarantine VLANs allow remediation without help-desk intervention for most compliance gaps

Continuous reassessment catches devices that drift out of compliance mid-session

Colonial Pipeline demonstrated the consequence of flat networks without admission controls: a single compromised VPN credential forcing a days-long pipeline shutdown

C2C is complementary to (not a replacement for) MFA, microsegmentation, and identity governance

Most mature deployments use a hybrid approach: 802.1X + agent + agentless for full device coverage

Frequently Asked Questions

How does C2C differ from traditional NAC?

Traditional NAC (circa 2005-2015) typically checked one or two criteria at admission -- valid certificate, correct VLAN membership -- and then granted indefinite access. C2C extends this with comprehensive posture assessment against a full compliance baseline (patches, STIGs, encryption, endpoint protection), continuous reassessment throughout the session, and dynamic re-quarantine when posture degrades. The difference is not architectural novelty -- it is operational depth.

What happens to users when their device is quarantined?

In a well-implemented C2C deployment, quarantine is not a dead end. The remediation VLAN provides access to patch servers, configuration update tools, and a self-service portal explaining exactly what failed and how to fix it. Most common quarantine triggers (missing patch, outdated AV definitions) can be resolved by the user in 5-15 minutes without a help-desk ticket. Only persistent failures (hardware trust issues, prohibited software, unresolvable STIG findings) require IT intervention.

Does C2C work for remote/VPN users?

Yes, but the enforcement point shifts. On-premise, 802.1X enforces at the switch port. For VPN connections, enforcement happens at the VPN concentrator: the always-on VPN agent checks posture before establishing the tunnel, and continuous reassessment monitors the remote device throughout the session. Split-tunnel VPN configurations require additional care -- the C2C agent must prevent access to protected resources via the tunnel while allowing internet access for remediation downloads.

How does C2C handle IoT and unmanaged devices?

IoT devices (printers, cameras, building automation, medical equipment) typically cannot run posture agents. C2C handles them through network-based profiling: the infrastructure identifies the device type via MAC OUI, DHCP fingerprint, and traffic patterns, then applies a device-type-specific policy. A networked printer gets placed on a restricted print VLAN with access only to the print server. A building automation controller gets isolated to its OT segment. Unknown devices get blocked entirely until an administrator classifies them.

What compliance frameworks require C2C or equivalent controls?

CMMC Level 2 (AC.L2-3.1.18, AC.L2-3.1.19), NIST 800-171 (3.1.18, 3.1.19), RMF (multiple controls in the AC and CM families), FedRAMP (AC-19, CM-8), and DISA STIGs all require device identification, posture assessment, or network admission controls in some form. C2C is the operational implementation that satisfies all of them simultaneously rather than addressing each framework's language piecemeal.

How Advisedly Helps

Advisedly maps your C2C posture data -- admission decisions, quarantine events, remediation timelines, device trust scores, and continuous reassessment results -- directly to the 500+ compliance framework controls that require device security evidence, then surfaces gaps automatically through our continuous monitoring engine so you know which devices are dragging your compliance posture down before your auditor does. Contact begin@advisedly.ai