Thank you for making time for CloudTweaks, Hiren. We are glad you are here. Before we dive in, could you briefly introduce yourself: who you are in your own words, your role as CEO & Founder at Teqtivity, and what the company does in the market today.
HH
Thanks for having me. I’m Hiren Hasmukh, the founder and CEO of Teqtivity. My background is in IT operations, and Teqtivity grew directly out of a problem I kept running into: organizations spend enormous effort securing and managing their environments, yet most of them can’t give you a straight answer to a basic question — what hardware do we own, and who has it right now.
Teqtivity is an IT asset management platform. We give organizations accurate, real-time visibility into their devices across the full lifecycle, from procurement and assignment through to offboarding and retirement. That means knowing what exists, who it’s assigned to, whether it’s under active management, and what happens to it when an employee or contractor leaves.
What sets us apart is that we treat hardware visibility as foundational rather than administrative. A lot of tools manage what’s running on a device. We make sure you actually know the device exists in the first place. In a world moving this fast on AI and security, that foundation is the part everyone assumes is solid and almost nobody has verified.
Thank you for that introduction, Hiren. We have a clearer sense of your role and what Teqtivity is doing in the market. Across the leadership conversations we are having right now, the same technology pressures keep appearing: how AI is embedding into everyday operations, how security and trust are keeping pace, and what those shifts demand from technology leadership. What was the moment that most sharpened your own thinking about how organizations should approach AI, and was it about adopting something internally, or something else entirely?
HH
Honestly, the moment that made us most thoughtful about AI wasn’t about adopting a specific tool. It was watching our customers rush to deploy AI across their organizations without knowing what hardware those tools were actually running on.
That’s what sharpened our thinking. Before you bring any new capability into your environment, you need to know what devices exist, who has them, and whether they can support what you’re asking them to do. AI doesn’t change that requirement. It makes it more urgent.
We call it asset intelligence before artificial intelligence. It’s not a position against AI. It’s a belief that the infrastructure underneath it has to be solid first. Organizations that skip that step are building on a foundation they haven’t verified. That’s where things get expensive.
That phrase “asset intelligence before artificial intelligence” captures a sequencing argument that a lot of leaders skip past entirely. When you watched customers deploy AI without that foundation in place, what did “expensive” actually look like for them?
HH
The pattern we see most often is AI tools getting pushed to endpoints that IT has lost track of. A device assigned to someone who left. Hardware in a remote office with no active management. The tool is live and running — IT just doesn’t know on what.
That’s where it gets expensive. Not because the AI tool failed, but because the unmanaged endpoint underneath it becomes a gap in your security coverage. Ghost assets don’t stop being a risk because you’ve deployed something new on top of them. They just become a harder problem to find.
The organizations that felt this most were the ones that moved fast on AI capability without first asking a simpler question: do we actually know what devices we own and who has them right now.
Ghost assets carrying live AI tools is a specific kind of blind spot that compliance frameworks rarely anticipate. As a lean team, shadow AI must look different for you than it does for a 10,000-person enterprise. How does that problem show up at your scale, and what’s the version of it you’re helping customers get ahead of?
HH
I’ll be honest — we’re a small, lean team, so the shadow AI problem looks different for us than it does for a 10,000-person enterprise. But the principle is the same.
What I can speak to is the hardware side of that problem. If you don’t have accurate visibility into which devices your employees are actually using, you have no starting point for knowing what’s running on them. Unsanctioned AI tools on untracked devices is exactly the scenario our customers are trying to get ahead of.
The question we help them answer first is the simpler one: what devices exist in your environment, who has them, and are they under active management? If you can’t answer that, the conversation about what software is running on those devices is premature. You’re trying to govern something you can’t see.
Governing something you can’t see is a pressure that extends beyond your own walls, into the vendors and partners who touch your customers’ environments. When a vendor in that supply chain has weaker asset visibility than the organization relying on them, where does that gap actually surface, and what does it tend to cost before anyone notices?
HH
Large enterprises don’t just manage their own devices. They’re managing hardware across contractors, third-party vendors, and distributed teams in multiple countries. The visibility problem compounds at every boundary. A device issued to a contractor three countries away sits in the same inventory as a device issued to a full-time employee in headquarters — or it should. Often it doesn’t.
What we see is that organizations assume their vendors have the same level of asset control they do. That assumption rarely gets tested until something goes wrong. An offboarding that doesn’t happen cleanly. A device that should have been retrieved that wasn’t. By the time the gap surfaces, the device has been outside active management for months.
The supply chain visibility problem is a hardware problem before it’s anything else.
That offboarding gap, a device outside active management for months before anyone notices, is exactly the kind of slow failure that rarely gets named until it becomes a headline. On that specific pattern, how do most organizations approach it early on, where does it break down, and what does the fix actually require?
HH
I’ll speak to what we’ve learned from our customers rather than a specific internal moment.
Early on, most organizations treat offboarding as an HR and IT access problem. Accounts get disabled, credentials get revoked. That part happens fast. The physical device is an afterthought. Someone sends an email asking for it back and hopes for the best.
What that costs is hard to measure until you run an audit and find devices that have been outside active management for six, eight, twelve months. Nobody flagged it because nobody was tracking it. The device didn’t disappear — it just stopped being anyone’s responsibility.
The fix isn’t complicated. Offboarding needs a hardware step that’s as automatic as the access revocation step. Until those two things happen together, the gap stays open. That’s what we help organizations close.
Pairing hardware retrieval with access revocation sounds straightforward, but getting two separate teams to treat it as one single step is rarely as clean as the logic suggests. For distributed teams spanning contractors and multiple countries, where does the zero-trust principle of “never trust, always verify” start to break down, and what has to be true underneath it for the framework to work as intended?
HH
The zero-trust conversation usually starts at the identity layer. Where it should start is the hardware layer.
The principle of “never trust, always verify” assumes you know what devices are requesting access in the first place. For distributed teams spanning contractors and multiple countries, that assumption breaks down fast. A contractor in a different country using a device that was never formally provisioned or tracked — that device is requesting access to your environment and nobody has verified it exists in any system of record.
That’s the friction we see. Not inside zero-trust frameworks themselves, but underneath them.
The hardware layer that zero-trust sits on top of has to be accurate for the framework to work as intended. If your asset inventory has gaps, your verification layer has gaps too.
The hardware layer as the foundation zero-trust actually depends on is a point the industry debates mostly in theory rather than in practice. When AI tools start touching production data or customer records and something unexpected happens, how ready are most organizations to respond, and what separates answering the “which devices were involved” question in hours versus days?
HH
Most organizations aren’t ready, and the reason usually traces back to the same problem we see everywhere else.
When something unexpected happens with an AI tool touching production data, the first question is: which systems were affected and what devices were involved? If your asset inventory isn’t accurate, that question takes days to answer instead of hours. You’re trying to scope an incident without a reliable map of your own environment.
Readiness isn’t just about having an incident response plan. It’s about having the foundational data that makes that plan executable. Which devices are active, who has them, what are they connected to. Without that, every response starts with a manual audit at the worst possible moment.
AI readiness and asset intelligence aren’t separate workstreams. Organizations that treat them that way find out why during an incident.
Incident response starting with a manual audit at the worst possible moment is a cost most leaders only quantify after they’ve paid it. On vendor assurance specifically, where does the gap usually hide, and what separates the organizations that get it right from the ones that find out the hard way?
HH
I’ll speak to what we see with our customers rather than a specific personal mistake.
The assurance question in vendor relationships almost always comes down to the same gap. Organizations assume their vendors and partners are managing hardware with the same discipline they are. That assumption rarely gets validated until something surfaces during an audit or an incident.
What we’ve learned is that assurance has to be structural. You can’t rely on a vendor telling you their asset management is solid. You need visibility into whether the devices touching your environment are tracked, managed, and accounted for. A vendor with ghost assets in their own inventory is a risk that doesn’t show up on a questionnaire.
The organizations that get this right build hardware accountability into vendor onboarding the same way they build it into their own offboarding process. The ones that don’t find out why eventually.