Case Study: GitHub Cuts Security Overhead With Control D

GitHub replaced a legacy DNS security setup that struggled with endpoint identification and agent overhead, and moved to Control D for lightweight deployment, clearer machine-level telemetry, and dramatically lower day-to-day maintenance.

The Challenge

GitHub had been using a DNS security product for years, but some issues kept surfacing:

1) Device identification didn’t line up with logs

They had longstanding problems accurately tying their DNS logs back to workstations. That’s a painful failure mode for DNS security: if you can’t confidently map “this request” to “this endpoint,” investigations slow down, and policy enforcement becomes harder to trust.

2) The “replacement” roaming client created friction

Those issues were compounded when their existing roaming client was deprecated, the replacement agent was heavier and introduced new problems, both directly on endpoints and through compatibility conflicts with other tools.

For a company operating at GitHub’s scale, endpoint friction isn’t a minor annoyance. It becomes tickets, lost hours, workarounds, and ultimately less confidence in the security stack.

3) Vendor responsiveness didn’t match the urgency

Requests to address the identification/log issues were met with what they described as a lackluster response. In practice, this meant the problems persisted long enough to justify looking elsewhere.

Why GitHub Chose Control D

GitHub discovered Control D in a practical, operator-friendly way: Control D was listed as a supported tool for Tailscale. That lent credibility and made it a natural fit in their ecosystem, worth a serious evaluation.

From the start, a few things stood out for the team:

• Lightweight feel (especially important after the “heavier agent” experience elsewhere)
• Straightforward UI that didn’t feel like a maze
• Pricing that made sense for what they needed
• Exceptional early interactions with the team

The biggest differentiator, though, was execution speed during the POC phase.

GitHub outlined security requirements that weren’t available at the time, specifically around admin access controls, and Control D moved quickly. The features they requested were ready to test in about a week, even before any licenses were purchased and while the team was explicitly still evaluating options.

That set a tone: Control D didn’t treat the POC like a waiting room.

“The word ‘soon’ from other vendors usually means something between 6 months and never, but the features we asked about were ready to test fairly quickly,” explained Ian Winsemius, Staff Security Manager at GitHub. “This was before we’d paid for any licenses, and we’d been clear we were still in a POC process,” he added. 

The Solution

GitHub rolled out Control D as its DNS security and policy layer with a focus on two immediate wins:

1) Reliable machine-level telemetry

Control D gave them the ability to track machines with unique identifiers, making it far easier to line up DNS activity with endpoint telemetry. That directly addressed the earlier pain point of device/log mismatch and made investigations and auditing feel grounded again.

2) Low-friction endpoint experience

Deployment was described as easy, with endpoint behavior remaining stable. Complaints were rare, and when they did happen, they were typically about specific domains, not “this tool broke my laptop” style issues. 

“We get very few user complaints, and when we do, it’s usually domains, not application behavior,” added Ian. 

Results & Impact

Less maintenance, more time back

GitHub’s most tangible operational outcome was simple: Control D gave them time back. After rollout, the system required very little day-to-day attention. That’s the kind of “result” teams feel immediately: fewer fires, fewer escalations, fewer hours spent babysitting a security agent.

“Control D is easy to deploy, and we’ve had to do very little to maintain it,” explained Ian. “And the response from the Control D team when we’ve had issues has been great.”

Higher internal trust in IT/security controls

Because endpoints weren’t generating constant issues, the team noted it helped them gain trust across the company. In practice, low-friction security tooling makes it easier for employees to accept policy changes because they don’t associate security with breakage.

“The lack of issues on user endpoints means that we gain trust with the company, and the simplicity overall means it's easy to jump back in when we do need to make changes,” added Ian.

Faster, cleaner policy enforcement

GitHub migrated their known lists over relatively easily, then improved enforcement using Control D’s built-in blocking capabilities, especially for categories like remote access tools, without constantly chasing down new IPs/domains for every tool variation. 

That reduced the “whack-a-mole” factor and made blocking more effective over time.

Lessons Learned

DNS security has to be attributable. If device identity and logs don’t reliably match, you lose time and confidence quickly.

Endpoint impact matters as much as threat blocking. A “secure” tool that causes endpoint instability creates its own operational risk.

POC responsiveness is a real signal. Shipping what matters quickly, before money changes hands, tells you how the partnership will feel later.