TL;DR: Tiggee’s acquisition of PerfOps combines DNS, CDN, cloud performance, and benchmarking capabilities, while retaining the PerfOps team and expanding troubleshooting features such as DNS checks over TCP or UDP, including DNSSEC, according to DigiCert. For practitioners, the lesson is that network observability and root-cause tooling are becoming part of the same operational and governance problem.
At a glance
What this is: This is an acquisition story about DNS, CDN, and cloud performance telemetry, with the key finding that consolidation is aimed at deeper troubleshooting and broader network visibility.
Why it matters: It matters because identity and access teams depend on reliable DNS and cloud telemetry for service integrity, incident response, and environment trust boundaries across NHI, autonomous, and human programmes.
By the numbers:
- After taking over as CEO in 2020, Filip Bujas and his team managed to grow monthly revenues by 500% in just over 12 months.
👉 Read DigiCert's coverage of the Tiggee and PerfOps acquisition
Context
DNS telemetry and cloud performance monitoring sit close to identity security because access paths, service trust, and troubleshooting all depend on accurate network signals. When those signals are fragmented across products and teams, security and operations can miss the root cause of failures that affect workload access and service availability.
This acquisition reflects a broader market pattern in which telemetry, benchmarking, and operational diagnostics are moving toward consolidation. For IAM and NHI programmes, the practical question is not who owns the brand, but how better visibility changes incident response, service-account troubleshooting, and the confidence teams place in their infrastructure controls.
Key questions
A: Security teams should validate DNS resolution, transport behaviour, and endpoint reachability before concluding that IAM, token, or service-account controls failed. In distributed environments, access symptoms often originate in the network path, not the identity control itself. Clear telemetry boundaries reduce false positives and help responders focus on the layer actually responsible for the outage.
Q: When should teams treat observability data as part of governance rather than operations?
A: Teams should treat observability data as governance evidence whenever service access, workload trust, or incident attribution depends on proving where a failure occurred. If a platform cannot explain the path from request to response, it cannot reliably support access reviews, incident triage, or accountability decisions.
Q: What do organisations get wrong about multi-cloud performance monitoring?
A: Organisations often compare environments using inconsistent measurements, which makes the data hard to trust. Multi-cloud monitoring only helps when latency, routing, and resolution are measured against a shared baseline. Without that discipline, teams optimise for symptoms in one environment while the real issue sits elsewhere.
Q: Who should own root-cause evidence when DNS and access issues overlap?
A: Ownership should sit jointly with platform operations and identity governance because the same incident can involve routing, resolution, workload access, and service trust. Clear ownership prevents teams from stopping at the first visible symptom and helps them preserve evidence for both recovery and post-incident review.
How it works in practice
How DNS checks over TCP, UDP, and DNSSEC change troubleshooting
DNS checks over TCP and UDP help teams validate resolver behaviour under different transport conditions, while DNSSEC-aware checks confirm that integrity protections are being honoured along the path. In practice, these checks turn DNS from a basic availability probe into a control signal for diagnosing propagation issues, validation failures, and resolver inconsistencies. For teams running distributed services, that distinction matters because a working endpoint can still hide a broken trust path. The technical value is in correlating query behaviour with network conditions rather than treating DNS as a single binary up or down signal.
Practical implication: build diagnostics that distinguish transport failure, resolver failure, and DNSSEC validation failure before escalating incident response.
Why multi-CDN and multi-cloud observability needs unified benchmarking
Multi-CDN and multi-cloud environments complicate troubleshooting because the same service can present different latency, routing, and resolution behaviours depending on geography and provider path. Benchmarking networks such as RUM and synthetic testing help teams compare real user experience with controlled probes, which is essential when teams need to know whether the issue is infrastructure, routing, or endpoint behaviour. The architectural point is that distributed delivery introduces ambiguity unless measurements are normalized across paths and time. Without that normalization, teams can overfit to one environment and miss the broader failure pattern.
Practical implication: standardize benchmark inputs across providers so network teams can compare failure modes instead of isolated symptoms.
Why performance telemetry is now part of service trust governance
Performance monitoring has become part of trust governance because availability, consistency, and root-cause clarity affect whether teams can safely rely on a service path. In identity-heavy environments, this matters when service accounts, API dependencies, or agentic workflows depend on predictable access to upstream systems. If the telemetry layer cannot explain where a failure occurred, governance teams lose the evidence needed to separate operational noise from access-control problems. That makes observability a governance input, not just an operations tool.
Practical implication: treat network telemetry as evidence in access and service trust reviews, not only as an operations dashboard.
NHI Mgmt Group analysis
Telemetry consolidation is becoming a governance issue, not just a tooling issue. When DNS, CDN, and cloud performance data move under one operational umbrella, teams can connect availability signals to trust decisions faster. That matters for identity programmes because service access failures often look like authentication or authorization problems until telemetry proves otherwise. Practitioners should treat observability ownership as part of service trust governance.
Root-cause visibility is now part of access reliability for machine and human workflows. The article shows an industry shift toward tools that help IT teams pinpoint network issues quickly, which is directly relevant to service accounts, API-driven workloads, and user-facing access paths. When access depends on distributed infrastructure, weak diagnostics increase mean time to understand, not just mean time to repair. Practitioners should evaluate whether their current monitoring stack can distinguish identity failure from network failure.
Unbiased benchmarking creates a stronger baseline for operational accountability. PerfOps’ positioning around neutral metrics matters because governance teams need consistent evidence when comparing service behaviour across providers and environments. That is especially useful in hybrid and multi-cloud estates where assumptions about reliability often outrun measurement discipline. Practitioners should insist on shared baselines before they debate remediation priorities.
Network observability is now adjacent to identity resilience because access paths are only as trustworthy as the signals behind them. DNS, CDN, and cloud telemetry do not replace IAM controls, but they determine whether those controls can be interpreted correctly during incidents. This is where lifecycle, service health, and trust evidence converge. Practitioners should fold telemetry review into broader identity and resilience operations.
From our research:
- 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility.
- For a practical next step, review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that often determine whether telemetry gaps become access gaps.
What this signals
Telemetry maturity will increasingly shape whether identity and infrastructure teams can agree on what broke first. As DNS, CDN, and cloud performance data become more central to operations, programmes need a clearer evidence chain between access symptoms and network causes. The governance risk is not just blind spots, but disputed ownership of the incident narrative.
With 35.6% of organisations citing consistent access across hybrid and multi-cloud environments as their top NHI challenge, per the 2024 Non-Human Identity Security Report, observability gaps are now part of the access problem. When the same workload behaves differently across providers, teams need telemetry that can explain variance rather than merely report it. That changes how security, operations, and architecture teams set priorities.
Multi-provider benchmarking will matter more as services become more distributed and more identity-dependent. Practitioners should expect root-cause evidence to become a required input for access reviews, outage analysis, and resilience planning. The organizations that can correlate identity signals with network telemetry will make faster, cleaner decisions under pressure.
For practitioners
- Map access failures to telemetry layers Separate DNS resolution issues, transport issues, and upstream service failures before you label an incident as identity-related. This reduces false attribution in NHI and IAM investigations and shortens triage when service accounts or workload identities are involved.
- Standardize benchmark baselines across environments Use the same latency, routing, and resolution metrics across multi-cloud and multi-CDN paths so teams can compare behaviour consistently. A common baseline helps operations and security teams identify whether a failure is environmental or systemic.
- Treat DNSSEC validation as a trust signal Include DNSSEC-aware checks in service monitoring where integrity matters, especially for externally resolved dependencies. This gives incident responders a clearer view of whether the problem is reachability, integrity, or misconfiguration.
- Review observability ownership in service trust reviews Assign responsibility for network telemetry, benchmarking data, and root-cause evidence alongside access governance so identity teams know where to verify service behaviour during incidents. The goal is faster correlation, not just better dashboards.
Key takeaways
- This acquisition is less about brand consolidation than about unifying the telemetry needed to explain DNS and cloud performance failures.
- The operational problem is attribution, because access symptoms in distributed environments often mask the real failure layer.
- Practitioners should align benchmarking, DNS validation, and identity governance so service trust can be assessed with evidence, not assumption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT-4 | Telemetry and DNS diagnostics support protective technology operations. |
| NIST CSF 2.0 | DE.CM-7 | Continuous monitoring is central to identifying when service paths drift or fail. |
| NIST Zero Trust (SP 800-207) | Distributed trust decisions depend on continuously verified service paths. |
Use PR.PT-4 to ensure monitoring can distinguish transport, resolution, and service failures.
Key terms
- DNS Telemetry: DNS telemetry is the collection of query, resolution, transport, and validation signals used to understand how name resolution behaves in production. In identity-heavy environments, it helps teams separate access issues from infrastructure issues and gives incident responders evidence about where a service path failed.
- Multi-cloud Observability: Multi-cloud observability is the practice of using shared metrics and traces to compare behaviour across cloud providers. It matters because access and availability problems often present differently by environment, so governance teams need consistent evidence before they assign root cause or ownership.
- Root-cause Evidence: Root-cause evidence is the technical and operational proof used to explain why an incident happened. For identity and infrastructure teams, it includes monitoring data, validation checks, and correlated events that show whether the failure began in access, transport, resolution, or application handling.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by DigiCert: Tiggee acquires PerfOps and expands DNS troubleshooting capabilities. Read the original.
Published by the NHIMG editorial team on 2026-06-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org