Safeguard.sh is in exploratory discussions with Sify Technology's US operations. The conversations are at a similar stage to the Tech-D Cybersecurity Ltd evaluation we wrote about earlier this year: technical due diligence, commercial modeling, and joint account review, but no signed agreement. Sify and Safeguard have distinct profiles, and this post lays out why we believe the combination is worth looking at seriously.
Sify Technology (USA) is the US-operating arm of Sify Technologies, a company with deep roots in enterprise network services, cloud infrastructure, and digital transformation consulting. Their footprint in the US market spans managed network services, data center interconnect, cloud migration, and a growing practice around security operations. Our interest in a partnership is not accidental. The layers of the stack where Sify operates — the network, the data center, the managed edge — are exactly the layers where Safeguard's platform has had less direct reach historically.
Why Consider a Network-Services Partner for a Supply Chain Platform?
At first glance, a supply chain security platform and a network services provider look like neighbors rather than teammates. Safeguard lives in the build pipeline, the artifact repository, the model registry, the runtime attestation layer. A network provider lives in transit, connectivity, and the operational edge. The connection becomes obvious when you follow a real customer's architecture.
A modern enterprise running Safeguard does not just scan images and issue SBOMs. They push attestations to a production artifact store. They serve those artifacts over a delivery network. They pull third-party models, containers, and packages from external registries across a set of networks that must be trusted, monitored, and segmented. They run signing infrastructure and transparency log mirrors that need availability guarantees. Every one of these is a networking problem as much as it is a security problem.
A partner like Sify, whose engineers routinely design private connectivity between enterprise data centers, hyperscaler cloud regions, and managed edge locations, would be able to weave Safeguard into that fabric with less friction than a customer or a generic SI could manage on their own. That is the thesis we are testing.
What Does the US Market Look Like for This Partnership?
Sify's US operations serve a mix of large enterprises, mid-market firms with Indian subsidiaries or vendors, and global organizations that need hybrid connectivity between US and Asia-Pacific locations. That customer profile overlaps, but does not fully duplicate, Safeguard's direct field motion. Where the overlap exists, it tends to be in financial services, healthcare, manufacturing, and communications — industries that buy network services, managed security, and supply chain security for different reasons but often from the same executive buyer.
The US regulatory environment is also a driver. Executive orders on software supply chain security, sector-specific rules from federal agencies, and procurement requirements that increasingly demand SBOMs, attestations, and VEX responses are pushing US enterprises to operationalize programs they did not have two years ago. When a customer has to produce an SBOM for every piece of software they ship or consume, they need tooling, process, and often a partner who can help them build the program. Sify has the relationships. Safeguard has the platform. A joint motion would give US enterprises a clearer path to compliance than either of us could deliver alone.
We are not saying Sify becomes our primary US channel. We are saying that for a specific slice of the market — particularly customers who already trust Sify for network and managed services and who are now under pressure to adopt supply chain security — a joint offer makes sense.
What Technical Integration Work Would Make This Real?
If the partnership moves forward, the technical collaboration would center on a few specific integration points. We have started to scope these with Sify's engineering team.
Private connectivity for Safeguard tenants. Customers who want a dedicated or private path to their Safeguard tenant — avoiding the public internet for artifact upload, attestation publication, or SBOM exchange — would be able to request that via Sify's network services. This is not a capability we have to build into Safeguard from scratch. It is a deployment pattern Sify already offers for other SaaS platforms, and we would formalize the configuration to support customers who want it.
Managed security operations center integration. If a customer runs their SOC through Sify or has SOC services delivered by Sify, the path from a Safeguard finding to an analyst queue needs to be first-class. That means well-documented event schemas, stable webhooks, and joint runbooks that describe exactly how a severity-high Safeguard finding shows up in the Sify-operated SOC and what the response looks like.
Cloud migration security workflows. Sify runs large enterprise migrations to public cloud. Those migrations are a natural moment to stand up supply chain security, because the target environment is being rebuilt anyway. Safeguard ESSCM and Griffin AI deployed during a migration is far less disruptive than bolting them onto a mature environment. A joint play here would include migration playbooks, pre-configured policy templates, and artifact baselines that match common target architectures.
Hybrid artifact and registry patterns. Many enterprises keep their package, container, and model registries in a split between private data centers and public clouds. Sify routinely designs this connectivity. Safeguard routinely scans across it. Jointly documented reference architectures — with attested delivery paths, signed mirror configurations, and failure modes that do not compromise provenance — would be valuable standalone content even if the partnership took longer than expected to formalize.
How Do We Avoid the Common Failure Modes of a US Partnership?
Partnerships involving a US-operating arm of a global parent carry specific risks. We are explicit with Sify about the ones we care about.
First, decision-making speed. If every commercial decision has to climb back up to a parent company structure, the partnership slows down and US-facing customers feel it. We are testing whether Sify (USA) has the autonomy to make real decisions on scope, pricing, and delivery commitments without long escalation cycles.
Second, field alignment. A signed partnership with a corporate logo means nothing if the field sellers on the ground never hear about it. Every successful partnership we have seen in this market has had a named partner manager, a joint account list, and a cadence of in-field activity between sellers. We would expect no less from a Sify relationship, and we are prepared to invest the same energy from our side.
Third, delivery consistency. Sify's US delivery quality has to match what a customer would get directly from Safeguard. That requires certification, joint accountability on outcomes, and a feedback loop for project retrospectives. Inconsistent delivery damages both brands, so the incentive to get this right is mutual.
Fourth, data residency and sovereignty. US enterprise customers increasingly have strong views on where their data lives and who has operational access. Any partnership motion has to respect that, and that usually means formal agreements on data handling — not just handshake assurances.
What Commercial Models Are Under Discussion?
Two models are on the table. The first is a co-sell agreement where Sify's US field team introduces Safeguard into mutual target accounts and earns compensation on closed deals. This is lightweight and easier to start. The second is a packaged offering where Sify bundles Safeguard into their managed security services portfolio, with Safeguard included in the catalog of things a Sify customer can purchase as part of a broader managed engagement. This is heavier but unlocks a distribution channel we cannot otherwise reach.
We are evaluating both. They are not mutually exclusive. A healthy partnership often starts with co-sell, proves out delivery through a handful of joint accounts, and then graduates into a bundled managed offering once both sides have confidence in each other's execution.
When Does the Exploration Reach a Decision Point?
The evaluation is scoped to roughly one business quarter. In that window we plan to complete technical due diligence, run two joint customer conversations, and produce a commercial model with enough specificity that the legal teams on both sides can open redlining. If that tracks, we expect a decision inside the quarter. If not, we will either extend the exploration by another checkpoint cycle or step back cleanly, and we will communicate either result.
Nothing about the exploratory phase affects the Safeguard roadmap, pricing, or support commitments. Sify has not been promised early access to unreleased features. They have not been given customer data to aid their evaluation. Any accounts that come up in conversation do so only when the customer consents to the introduction.
How Safeguard.sh Helps
If your organization works with Sify Technology in the US for network or managed services and you are curious what a combined Safeguard plus Sify engagement might look like, the most useful thing you can do right now is tell your Sify account team and your Safeguard account team that you are interested. That signal shapes which commercial model we prioritize and which joint playbooks we invest in first. Customers who buy Safeguard directly today are unaffected by the exploration, and direct customers will remain a first-class motion regardless of how partnerships evolve. Our commitment is that any path into Safeguard — direct, through a services partner like Tech-D, or through a networks-plus-managed-services partner like Sify — delivers the same platform, the same support quality, and the same roadmap transparency. That consistency is what a partner strategy actually has to protect.