Vendor Telemetry Limitations

A healthcare payer's data management vendor operated across a hybrid environment: primary workloads in Azure, a legacy on-premise database containing seven years of patient-attributed claims history, a Microsoft Teams and SharePoint environment for internal collaboration, and a contractor VPN providing access for their offshore data processing team. The Azure environment was comprehensively instrumented , Defender for Cloud, Azure Monitor, Sentinel integration, and detailed activity logs for all resources. The on-premise database had minimal logging enabled because the database vendor's licensing model charged by log volume and the cost of enabling full query logging had been deemed prohibitive during a cost reduction exercise three years earlier. The Microsoft Teams environment generated activity logs, but those logs were only accessible through the Microsoft Purview compliance portal and could not be exported to the Sentinel SIEM without a specific connector configuration that the IT team had not implemented. The contractor VPN generated connection event logs , source IP, session duration, bytes transferred , but no session content or activity logs. When a supply chain attacker who had compromised a contractor credential gained access through the VPN, accessed the collaboration environment to map the organisation's data holdings, and then used the database server to stage a bulk extract, the SIEM had minimal visibility into any of the three attack stages: no contractor session activity logs, no collaboration environment activity in the SIEM, and no database query logs. The Azure environment generated no alerts because the attack did not touch Azure.

What are Vendor Telemetry Limitations, Really?

Telemetry limitations are the gaps in the volume, detail, and coverage of security-relevant data that a vendor's monitoring infrastructure has access to , gaps that constrain what the SIEM can detect regardless of how mature the detection rules and SOC operations are. SIEM effectiveness is bounded by the telemetry it receives: a SIEM that receives rich, detailed logs from all relevant systems can detect a wide range of attack patterns. A SIEM that receives minimal logs from critical systems, no logs from specific environments, and connection-only data from high-risk access pathways cannot detect attacks that are visible only in the missing data.

The cost-driven telemetry reduction problem is the most common source of telemetry limitation. Many log sources , databases, network devices, and legacy systems , charge for extended logging capability or generate significant storage costs at full logging levels. IT teams facing budget pressure make pragmatic decisions to reduce log verbosity or disable specific log categories to manage costs. These decisions are individually justifiable on cost grounds. Their aggregate effect on SIEM detection capability may not be visible to the security team if the cost decisions are made outside the security programme's awareness.

The SaaS platform telemetry accessibility problem is a growing limitation in modern environments. SaaS platforms generate activity logs, but those logs may be accessible only through the platform's native compliance portal rather than through export APIs that would enable SIEM integration. Microsoft Purview, Google Workspace Admin, and Salesforce Event Monitoring all provide activity logging , but enabling SIEM integration requires specific connector configuration that may not be in place. The logs exist. They are not in the SIEM. Threats visible in the SaaS platform's activity logs are invisible to the SOC's primary monitoring tool.

• Cost-driven logging reduction , database and legacy system logs minimised to reduce costs
• SaaS platform logs not in SIEM , accessible only through platform UI without connector configuration
• VPN session content absent , connection logs without activity data
• Telemetry gaps in attack path , three attack stages in unmonitored systems
• SIEM coverage assessed without telemetry quality , integration confirmed but log depth not verified

Why this matters

Vendor telemetry limitations matter for TPRM because they create attack path visibility gaps that are invisible to the vendor's SOC and to the customer's TPRM assessment. The healthcare payer's attacker used three systems , the contractor VPN, the collaboration environment, and the on-premise database , each of which had minimal or inaccessible telemetry. The attack was invisible to the SIEM not because the SIEM was poorly deployed but because the telemetry it needed was not available from any of the three systems the attack used.

Where most teams get this wrong

The most consistent failure is accepting SIEM deployment confirmation as equivalent to comprehensive telemetry coverage. SIEM deployment confirms that a log aggregation platform is in place. Telemetry quality assessment confirms what log detail is available from each source system.

• SIEM deployment confirmed without telemetry quality , integration confirmed but log depth not assessed
• Database logging levels not asked , verbosity not verified
• SaaS platform SIEM integration not verified , Teams, Salesforce, Google Workspace connector status
• VPN session content logging not assessed
• Cost-driven logging decisions not surfaced in security assessment

What good looks like

Mature telemetry programmes maintain a telemetry inventory that maps each source system to its logging level, assesses gaps against detection requirements, and tracks remediation of identified telemetry gaps , treating inadequate telemetry as a detection risk rather than a cost management decision.

• Telemetry inventory , source system, logging level, SIEM integration status
• Database query logging enabled for systems containing sensitive data
• SaaS SIEM connectors configured , Teams, Salesforce, Google Workspace integrated
• VPN session activity logging enabled for contractor access
• Telemetry gap remediation tracked and prioritised by attack path risk

Tooling

SIEM Connectors , Microsoft Sentinel data connectors, Splunk Add-ons

SIEM platforms provide extensive connector libraries for SaaS platforms and cloud services. The gap between what connectors exist and what connectors are configured is the telemetry coverage gap. For TPRM practitioners, asking for the vendor's SIEM data connector inventory , which sources are connected at what logging level , provides the telemetry quality assessment that deployment confirmation does not.

Governance challenges

The governance challenge with telemetry limitations is the cost-security trade-off. Full query logging on a large database is expensive. Full SaaS activity log integration adds complexity. The governance resolution is risk-based telemetry investment , prioritising full logging for the systems on the most likely attack paths rather than applying uniform logging levels across all systems.

• Request telemetry inventory , source system, logging level, SIEM integration
• Ask specifically about database query logging for systems containing sensitive data
• Ask about SaaS platform SIEM integration , Teams, SharePoint, Salesforce
• Ask about VPN session activity logging for contractor and partner access
• Ask about cost-driven logging reductions and their security impact assessment

If you are a small team

For your highest-risk vendor, ask one question about their telemetry coverage for the three systems most likely to be on the attack path to your data: the database or data store containing your data, the identity or access system used for contractor or partner access, and the collaboration or communication platform where data handling decisions are made. For each of those three systems: what logging level is enabled, and are those logs in the SIEM? Those three questions map the telemetry quality for the most attack-path-relevant systems.

• Ask logging level and SIEM integration for database containing customer data
• Ask about contractor access system logging
• Ask about collaboration platform SIEM integration
• Ask whether cost reductions have affected security-relevant log verbosity

What to require

Ask directly:

"For the three systems most directly on the access path to our data , the data store, the access control system, and the contractor access pathway , what is the logging level enabled on each, and are those logs being forwarded to your SIEM?"

Expect as evidence

• Logging level by source system for attack-path-relevant systems
• SIEM integration status for each source
• SaaS platform connector configuration
• Database query logging status

A vendor who confirms comprehensive SIEM coverage should be asked for the telemetry inventory for the specific systems on the attack path to customer data. SIEM coverage describes what is connected. Telemetry quality describes what that connection provides.

How to evidence it

• Telemetry inventory records
• Database logging level documentation
• SaaS connector configuration records
• Telemetry gap remediation tracking

Key Takeaway

The SIEM was Sentinel with comprehensive Azure integration. The attack used the contractor VPN, the Teams environment, and the on-premise database. Three systems. Minimal or inaccessible telemetry on each. The attack was invisible not because the SIEM failed but because the telemetry it needed did not arrive. Telemetry is the SIEM's raw material. A SIEM receiving poor telemetry produces poor detection regardless of the rules built on top of it. The telemetry inventory for the attack-path-relevant systems reveals the detection quality for the threats that matter. Request it.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations