No Is Not a Security Policy

A researcher came to me with a simple request.

She needed to take pictures of plants.

Specifically, she needed to photograph leaf samples in the lab, upload them to a SharePoint folder, and let an AI model measure the growth patterns automatically — tracking whether the company’s fertilizers and pesticides were helping crops or hurting them. The science was sophisticated. The ask, on the surface, seemed simple.

She wanted iPads.

I told her no.

The room I was walking into

A global agricultural research company’s North American headquarters in Durham was not a typical corporate office. The region employed around 500 people across North America, Canada, and Mexico — but the Durham facility itself was the research center, home to roughly 100 people. Other than a handful of logistics staff, everyone there held either a PhD or a senior sales title. The median salary in that building was somewhere around $200,000.

I had no advanced degree. I had, at that point, never heard of a mass spectrometer.

What I did have was a clear understanding of what our network security requirements were, what Active Directory integration meant for shared device access, and what happened when you introduced consumer devices into an enterprise environment without thinking it through.

The iPad request wasn’t malicious. It was intuitive. iPads are good cameras. They’re easy to use. They connect to SharePoint natively. For someone whose job is plant biology, not IT architecture, it’s an obvious solution.

The problem was everything underneath it.

Why the obvious solution was the wrong solution

The workflow required multiple researchers to access various SharePoint sites and network locations. On the surface, that’s easy — share a folder, done. But shared access without Active Directory integration means you’re managing permissions outside your identity system. You’re creating access pathways that your security policies can’t see, can’t audit, and can’t revoke centrally when someone leaves the organization or changes roles.

In a research facility handling proprietary scientific data, that’s not a theoretical risk. It’s a compliance problem. I couldn’t let it happen.

Beyond that, these tablets needed to be available to multiple people, in multiple lab locations, with access to multiple points on the network. That’s not a consumer device use case. That’s an enterprise endpoint. Consumer iPads aren’t built to live in that environment cleanly — not without workarounds that create their own problems and maintenance overhead.

I needed these devices in Active Directory. iPads couldn’t do that. Not the way this deployment needed to work.

The pushback

The researcher went to the Chief Scientific Officer. The CSO escalated it. It went all the way up the chain.

I made my case. Here’s the security exposure. Here’s the compliance issue. Here’s what we need from any device that’s going to operate in this environment. This isn’t about convenience — it’s about what happens when someone leaves and we can’t cleanly revoke their access, or when we get audited and can’t show a clean chain of custody on research data.

The decision came back in my favor.

But I want to be clear about something: winning that argument wasn’t the goal. Finding the right answer was.

What actually happened

I went looking for a Windows tablet that could genuinely function as a tablet — not a laptop in tablet clothing, but something with a good camera, a touch-first interface, and real portability — while still integrating cleanly into Active Directory.

We found it.

The researchers got their tablets. They got the camera workflow they needed. They got shared access to SharePoint and the network locations they needed, with proper AD-backed permissions. The AI model got its leaf photographs. The security team got auditable, centrally managed endpoints that followed the same policies as every other device in the organization.

Nobody had to compromise. The researchers got their workflow. The organization got its security posture. Nobody had to choose between them.

What it taught me

Security theater is what happens when IT says no without offering a better yes.

The easiest thing I could have done in that situation was block the request, cite the policy, and move on. Technically correct. Operationally useless. And it would have left a group of researchers doing workarounds that were probably less secure than the original ask.

The harder thing — and the more valuable thing — was understanding what they actually needed, finding a solution that met both sets of requirements, and being able to defend it clearly enough that it survived a challenge at the highest levels of the organization.

That’s what IT leadership actually looks like. Not the person who guards the network. The person who figures out how to give the business what it needs without leaving the door open.

The plants, for what it’s worth, were fine.