Modern IdPs and device‑trust products—JumpCloud, Okta/Microsoft Entra, 1Password Extended Access Management (Kolide)—have pushed Zero‑Trust far beyond the perimeter. They verify who you are, check which device you’re on, and then hand you a green light to sign in.

But the second a developer trades the web UI for a git clone, that trust collapses. GitHub’s own docs are blunt:

“After you authorize a personal access token or SSH key, the token or key will stay authorized until revoked.” GitHub DocsGitHub Docs

That single sentence explains why adversaries target build servers and developer laptops, not login pages. Below we unpack how today’s best‑in‑class device‑trust stacks still leave this token loophole wide open—and how EDAMAME plugs it without breaking developer flow.

1. How Device‑Trust Works Today (and Where It Stops)

Solution family	Example vendors	What they do protect	Where they stop
Cloud IdP + Device Trust	JumpCloud Device Trust, Okta Device Trust / FastPass, Microsoft Entra CA	Block SSO if device lacks certificate or health signal (at login to GitHub, GitLab UI, Jira, etc.) JumpCloud, help.okta.com	Once a PAT/SSH key is authorized, every subsequent Git or API request bypasses IdP checks.
MDM / UEM	Intune, Jamf, VMware WS1	Enforce OS patching, disk‑enc, config across corporate fleet	BYOD & contractors often un‑enrolled; can’t block a single Git push from a non‑compliant device.
New Device‑Trust Add‑Ons	1Password EAM / Kolide Device Trust integrates as an Okta factor 1password.com, Kolide	Same as IdP trust: great during SSO, user gets remediation prompts	After login, the PAT or deploy key lives outside the trust boundary; CI runners & scripts run unchecked.

Bottom line: All three categories excel at sign‑in time; none verify the device each time code moves.

2. The GitHub Token Reality Check

GitHub SSO forces you to “Configure SSO” when you create a PAT or add an SSH key—but only once. After that:

The PAT/key is valid from any IP, on any machine, until it expires or you manually revoke it.
No MFA challenges, no device inspection, and crucially no IdP context on each use.
The same model applies to GitLab deploy tokens and many CI secrets.

Attackers know this. They phish or exfiltrate developer tokens, drop them on a disposable VPS, and siphon code undetected.

3. Why 1Password/Kolide & Friends Still Miss the Mark

JumpCloud & Okta/Microsoft Entra

These platforms issue a device certificate and check it while the browser is talking to the IdP. Once Git uses HTTPS+PAT or SSH over port 22, the IdP is out of the path.

1Password Extended Access Management (Kolide)

Kolide’s agent enforces compliance and can block the Okta login screen on a non‑compliant laptop Kolide, 1password.com. Fantastic UX, but still bound to the same web‑SSO window. When your CI runner re‑uses last night’s PAT, Kolide isn’t invoked.

Result

No matter how new the device‑trust tech, if it sits only at SSO it can’t stop:

A leaked PAT in CI logs
An engineer copying their ~/.ssh/id_ed25519 to a personal desktop
Malicious code pushes from an infected but previously compliant laptop

4. EDAMAME’s Layer: Device Trust After the Token

EDAMAME integrates at the Git host itself:

Dynamic IP Allow‑List
- Hooks into GitHub Enterprise (and GitLab) APIs.
- Adds the public IP of a device only if it just passed a real‑time posture scan (patch level, AV, firewall, OS integrity).
- Removes the IP the moment posture fails.
Token‑Aware Enforcement
- GitHub/GitLab evaluate the allow‑list before they touch credentials.
- A PAT or SSH key from an off‑list IP returns HTTP 403—instantly neutralising leaked secrets.
BYOD‑Friendly, No Heavy MDM
- Lightweight read‑only agent or agent‑less script reports posture.
- Contractors on personal hardware can join without full‑device takeover.

5. Capability Matrix (Zoom In)

Capability	JumpCloud / Okta / 1Password EAM	EDAMAME + GitHub/GitLab
Block login from unmanaged device	✔︎ (SSO page)	n/a (relies on IdP)
Block Git clone/push from unmanaged device	✖︎	✔︎ (IP allow‑list)
Protect PATs / SSH keys / CI tokens	✖︎	✔︎ (useless off trusted IPs)
Works with unmanaged contractor laptops	Often requires full enrollment, no guarantee of admin console abuse to confidentiality	Yes (posture attestation only - full guarantee of confidentiality)
Continuous assessment every Git request	✖︎	✔︎
Developer friction	High to Low	Low (silent)

6. Real‑World Flow

Dev signs into GitHub → JumpCloud/Okta/1Password verify identity & device.
Dev creates PAT for CI → GitHub prompts once for SSO; PAT now lives forever. GitHub Docs
Pat leaks to attacker VPS → IdP never sees traffic.
EDAMAME active?
- VPS IP not on allow‑list → GitHub rejects.
- Compromised laptop falls out of compliance → EDAMAME removes its IP; next git push fails until patched.

7. Take‑Aways for Security & DevOps Teams

Device‑trust at login ≠ device‑trust for Git operations.
All mainstream IdP/MDM stacks—JumpCloud, Okta/Entra, 1Password EAM/Kolide—share this gap because Git credentials outlive the SSO session.
EDAMAME stitches the final mile, forcing every byte of code to travel only between secure, compliant endpoints—even in headless CI jobs, even with long‑lived keys.
Deploy EDAMAME alongside your existing IdP and device solutions; you don’t replace them, you fortify them.

Close the token loophole—turn Zero‑Trust rhetoric into SDLC reality.

Frank Lyonnet

Share this post

The Token Loophole: Why Even the Newest Device‑Trust Solutions Still Miss a Critical SDLC Gap