Case Study: Pennsylvania College of Technology Closes Its BYOD Security Gap With Control D

About Pennsylvania College of Technology

Pennsylvania College of Technology is an applied technology college in Williamsport, Pennsylvania. Its campus network reflects the daily reality of higher education IT: thousands of personal, unmanaged devices connecting alongside institutional ones, with no straightforward way to secure them.

Ian Bell, Security Operations Engineer at the college, is responsible for protecting that network. We spoke with him about what brought the college to Control D, what the rollout has looked like, and what it has already produced.

The Challenge

Higher education has a security constraint that most industries don’t face: the devices most likely to be compromised are the ones IT can’t touch.

Student-owned laptops, phones, and tablets connect to the campus network every day, but a college can’t monitor and control a student's personal device the way an employer can a company-issued one.

Ian accepted that boundary, but it meant that the entire Bring Your Own Device (BYOD) population was effectively invisible from a security standpoint.

For a period, a free protective DNS resolver covered the basics. It was better than nothing and better than an unfiltered resolver. But over time, the limitations inherent to that approach became more apparent.

"The most important issue for us, and the reason we moved to a managed protective DNS service, was that free resolvers lack logging."

Without logs, there was no record of which devices were resolving which domains, no way to identify a personal device communicating with malicious infrastructure, and no trail to follow when something went wrong.

"It is not appropriate to install an EDR product on student-owned devices because of privacy implications. A less invasive middle ground that allows us to identify personal devices that may be compromised is DNS resolution logging."

For a student population where endpoint agents were never an option, there was no other way to close that gap. 

On top of the visibility problem, the college was facing a threat environment that existing tooling was not built to handle.

"We regularly see targeted attacks for which there is no public threat intelligence available, and because of that, we need to be able to block threat actor infrastructure as we identify it."

The Solution

Ian had been using Control D on his personal networks for several years, having worked through alternatives including Pi-hole and NextDNS. When the college needed a managed protective DNS resolver with real logging and manual controls, Control D was the natural starting point for evaluation.

Several capabilities have already been put to use.

1. Logging that covers the devices you cannot agent

DNS resolution logging is what makes the BYoD population visible without touching personal devices. A student's laptop querying a known malicious domain shows up in the logs, and the team can act on it. Without that log, the same query happens, but it doesn’t get flagged or blocked.

2. Acting on intelligence before it appears anywhere else

Manual block and allow controls give the security team the ability to respond to threats as they find them, not after it has been cataloged in a public feed. Control D also extends that capability further than any comparable product Ian had evaluated.

"To my knowledge, no other managed protective DNS product lets you build custom rules based on source/destination IP address geolocation, ASN, or CIDR range. That capability will be valuable as we identify attacker infrastructure tied to things like bulletproof hosting ASNs."

Blocking by ASN or CIDR range means the college can take out entire hosting providers used by attackers, rather than chasing individual domains that can be rotated within minutes.

3. Configurable block responses

The college's previous resolver returned NXDOMAIN for blocked domains. That behavior had two practical advantages: broad compatibility across client types on the campus network, and an error visible enough in browsers that support staff could spot a potential false positive.

"With Control D, we can set the block response to whatever works best for our situation. Down the line, we may redirect blocked domains to an internal honeypot to get more visibility into potentially compromised devices."

4. An architecture that does not force a tradeoff

Most DNS security products bundle device identity and filtering settings together. That sounds convenient, but it creates a problem: you either get centralized policy management or the ability to trace activity back to individual devices, but not both.

"Separating Endpoints from Profiles is unique to Control D. Other products conflate the two, which makes it harder to trace where queries are coming from, or it duplicates configuration changes when adding custom domain blocks or allows. With Control D's approach, we get centralized management and detailed logging. We don't have to choose one or the other."

The Control D API extends that operational flexibility further, giving the team a way to programmatically push changes, automate responses, and connect Control D to the rest of their security stack as the implementation grows.

Results and Impact

1. Threats that were previously invisible are now being caught

"Control D's logging has already helped us identify phishing campaigns and other malicious activity."

The BYOD population, previously a structural blind spot, now generates an actionable signal. When a personal device starts querying infrastructure tied to an active threat, the team sees it.

2. Fewer compromised accounts and devices

"We're detecting and disrupting threats we simply couldn't see before, especially across our BYOD population. It's helped us reduce compromised accounts and devices, and cut the risk that a breach goes unnoticed entirely."

For any higher education institution dealing with the same tension between student privacy and network security, the logic here is straightforward. 

DNS is where you get visibility into devices you can’t put an agent on. And if you are going to use DNS for that purpose, you need logging, manual controls, and the flexibility to act on your own intelligence. That combination is what brought the college to Control D.