Safeguard.sh is currently in early-stage discussions with Tech-D Cybersecurity Ltd to evaluate whether a formal partnership would make sense for both companies. Nothing is signed. No go-to-market contract is in place. What we have is a series of working sessions, a shared curiosity about each other's customer base, and enough architectural overlap to justify a serious look.
We are publishing this note because transparency matters in the partner ecosystem. Customers, prospects, and existing partners are going to hear about these conversations, and it is better that the framing comes from us directly. A partnership with Tech-D would not change what Safeguard does. It could, however, change where and how we show up in the market.
What Is Tech-D Cybersecurity and Why Are We Talking?
Tech-D Cybersecurity Ltd is a cybersecurity services firm with a delivery-first culture. They do the work that most product companies either do not want to do or cannot scale: hands-on integration, tuned detections, bespoke threat modeling, and the long-tail support that enterprise customers actually pay for. Their engagements are typically multi-quarter, their engineers sit with customers, and their value is measured in reduced dwell time rather than shelfware.
Safeguard.sh is a platform company. We build software for software supply chain security, SBOM management, AI/ML model provenance, policy automation, and vulnerability remediation. We do ship implementation services, but our center of gravity is the product. The gap between what a platform vendor ships and what an enterprise actually operationalizes is real, and it is exactly the gap a services partner like Tech-D is built to fill.
The reason we are talking is simple. Customers keep telling us they want Safeguard to solve the problem end to end — not just license the platform, but stand it up, tune it, integrate it, and operate it alongside existing tooling. We can meet that demand in three ways: hire an army of field engineers, outsource the work to a generic SI, or partner with a specialist firm that already thinks about security the way we do. The third option is the one under consideration.
What Would a Partnership Actually Enable?
If the conversations progress to a formal arrangement, the most likely shape is a hybrid co-sell and delivery motion. Safeguard would remain the platform of record. Tech-D would bring professional services, managed detection and response adjacencies, and the kind of regional coverage we do not currently have.
Concretely, we are exploring four areas:
Joint delivery on complex deployments. Enterprise rollouts of Safeguard ESSCM, Griffin AI remediation, and AI-BOM workflows can involve dozens of teams and hundreds of repositories. Tech-D's engineers would handle the customer-facing deployment, policy tuning, and integration work. Safeguard would back them up with product expertise, escalations, and engineering-to-engineering support.
Co-sell into Tech-D's installed base. Tech-D has relationships with customers we do not yet reach. A co-sell agreement would let Tech-D introduce Safeguard into those accounts with a delivery wrapper attached. This is a classic SI motion — the customer gets one partner to call, the partner gets margin, and the platform vendor gets reach.
Shared L2/L3 support for managed customers. For customers who buy Safeguard through Tech-D as a managed offering, we would align on escalation paths, runbooks, and SLAs. Tech-D handles tier one and two. Safeguard engineering picks up tier three and product-level issues.
Joint threat research and content. Tech-D's incident response team sees attack patterns that our telemetry does not always catch. A content-sharing arrangement — anonymized indicators, detection rules, tuning recommendations — would improve both product and services outcomes.
None of this is unique to the Tech-D relationship. It is how mature partnerships in this market actually work. The question we are evaluating is whether Tech-D specifically is the right partner for this motion, versus the two or three other firms we have talked to.
What Are We Looking For in a Services Partner?
Every platform company gets approached by services firms wanting a logo and a referral agreement. Most of those conversations end quickly because the fit is not there. Here is the short list we use internally.
Technical depth in the specific domain. We do not need a generalist MSP. We need engineers who have actually shipped SBOM workflows, tuned SLSA attestations, responded to a real supply chain incident, and can hold their own in a design review. Tech-D clears this bar on the engagements we have reviewed so far.
Commercial alignment on how value is split. A partnership fails when the partner wants to resell but not deliver, or deliver but not resell, or when margin expectations are misaligned with the deal economics. We spend real time on this during exploration because it is where most relationships break.
Operational maturity. A partner needs a project management office, predictable delivery, documented methodologies, and a way to report status back to us for joint accounts. Handwaved processes do not survive a multi-region enterprise rollout.
Cultural fit. This one sounds soft but is not. Our engineering culture is direct, artifact-heavy, and allergic to marketing language in technical contexts. A partner whose engineers cannot hold a straight conversation about a memory-safe language migration or a Sigstore verification flow is not going to work. We have been encouraged by the technical conversations with Tech-D so far.
What Is Not Changing, Regardless of How This Plays Out?
We want to be direct with customers and the ecosystem about what a Tech-D partnership would and would not mean.
Safeguard's roadmap remains independent. No partner dictates what we build. Product priorities are set by our engineering and customer input, not by a services firm's delivery calendar.
Direct support is not going away. Customers who buy Safeguard directly will continue to get direct support from our team. A managed offering through Tech-D would be additive, not a replacement.
Pricing is not going up because of this. Partnerships change distribution, not list price. Any managed services markup would be Tech-D's decision on their side of the contract and would reflect the delivery they provide.
Data stays where it belongs. A services partner with access to a customer's Safeguard tenant only gets the permissions that customer explicitly grants. There is no back-channel data sharing, and there would not be under any arrangement we would sign.
When Will We Know More?
Honest answer: we do not have a fixed timeline. Partnership discussions in enterprise security typically run three to six months from first conversation to signed agreement, and we are closer to the front of that window than the back. The current work is technical due diligence — reviewing each other's delivery methodologies, running a couple of joint customer conversations under NDA, and stress-testing the commercial model.
If we reach an agreement, we will announce it clearly with scope, timing, and what it means for customers. If we do not, we will say that too. We will not leave the ecosystem guessing or let speculation fill the vacuum.
How Safeguard.sh Helps
For customers wondering what this means for them right now, the answer is straightforward. If you are an existing Safeguard customer, your contract, roadmap exposure, and support channels are unchanged. If you are evaluating Safeguard and have a preference for buying through a services partner, tell your account team — we will route the conversation appropriately, whether that is Tech-D, another firm under consideration, or a direct engagement. If you are a services firm reading this and wondering how to partner with Safeguard, our channel team is accepting new conversations, and the evaluation criteria above are a reasonable preview of what we will ask. The goal of every Safeguard partnership — exploratory or signed — is to make the platform easier to deploy, operate, and extract value from, without compromising the independence that got us here.