API Rate Limits and Polling Lag in Multi-Tool Security Stacks

Security tools don't share data in real time. They ask for it, on a schedule, and that schedule is the whole problem. Most integrations in a security stack run on polling: one tool requests updates from another every few minutes, sometimes every hour, and calls that a live feed. Fine for a dashboard, maybe. Wrong pattern, structurally, for catching a threat while there's still time to do something about it. The industry keeps building on polling anyway, because polling is the easier thing to ship, and shipping fast has won out over getting the architecture right.

Rate limiting and throttling are distinct failure modes with different consequences for a security pipeline. Rate limiting triggers an HTTP 429 and rejects the request outright, which means the data attached to that call is simply gone, not delayed. Throttling accepts the request, queues it, and delivers the data late, with no error surfaced anywhere in the pipeline, so the collecting tool has no way of knowing its view of events is stale. Microsoft Graph enforces a ceiling of 800 requests per hour per tenant, and Microsoft's own guidance pushes polling intervals to 10 to 30 minutes just to stay under it, which sets the floor for how long any event routed through that connection can stay invisible to detection. The silent failure is the worse one: some Graph requests take over a minute to return with no 429 and no flag, so from the collecting tool's side the event looks like it never happened rather than like it arrived late.

Rate limiting and throttling get used interchangeably, but they fail in different ways, and the difference matters more than most integration docs let on. Rate limiting rejects a request outright once a client crosses its allotment, typically returning an HTTP 429 ("Too Many Requests"), and the data attached to that rejected request is just gone. Throttling is quieter: the request gets accepted, then queued and delayed, so the data eventually shows up, just not when it happened. One fails loud. The other fails silent, and silent is worse, since nothing in the pipeline flags it for anyone to go looking.

Microsoft Graph makes the clearest case study, mostly because so much of the SMB and mid-market security world sits on top of it. The Graph Service Communications API allows 240 requests per 60 seconds and 800 requests per hour, per tenant. Cross 800 in an hour and that client starts getting 429s. Microsoft's own guidance tells integrators to poll no more often than every 10 minutes, and preferably every 15 or 30, just to stay under the ceiling. That interval isn't a suggestion about efficiency. It's the floor of how long anything routed through that connection can stay invisible to whatever's supposed to be watching it.

The worse failure mode never throws an error at all. Some Graph requests simply take over a minute to return, with no 429, no flag, nothing indicating the API throttled the call silently. From the collecting tool's side, the event didn't fail to arrive: it looks like it never happened. That gap stays undetectable unless someone is specifically watching pipeline latency, and almost nobody watches pipeline latency. This isn't a Microsoft quirk, either. Research published in the ACM Digital Library found only 47% of surveyed public APIs implement explicit rate limiting at all. The rest throttle inconsistently or silently, which means a SIEM polling one of them can be confidently wrong about how current its own data is, with no way of knowing it.

How fast attackers actually move inside the window that polling creates

Initial access to breakout can take minutes, not days. Documented intrusion timelines put the handoff from initial access at around 22 seconds, according to Vectra, with full breakout following shortly after. That's the speed detection has to beat. Average breach dwell time still runs into the hundreds of days, but that number describes slow detection, not slow attackers. The attacker isn't idling. The stack is.

A five-minute polling interval means an attacker who starts moving one minute after compromise gets a four-minute head start before any tool even has a chance to see the first indicator. Credentials get harvested in that window. Lateral movement begins. Persistence gets established, quietly, while the polling clock ticks down to its next check-in.

Low-and-slow attacks exploit this on purpose, and this is where most SIEM detection logic gets caught flat-footed, because it's built to catch volume, not patience. Instead of triggering volume-based alerts, attackers spread requests thin across time, staying under whatever threshold would normally light something up. Red team playbooks document the tactic explicitly: move slowly, stay under the rate limit, let the polling interval do the hiding. It works because the vast majority of real API attacks aren't brute-force noise from the outside in the first place. Salt Labs' state-of-API-security research found 95% of API attacks over the prior 12 months came from authenticated sessions, meaning the rate limits guarding those authenticated tool-to-tool integrations are exactly the limits attackers have already learned to work around. High latency in a collection pipeline isn't a performance nuisance here. Functionally, it's no detection at all, for as long as the lag lasts, and lag is the default state, not the exception.

Where do SIEM integrations fail when they rely on polling to collect logs?

Polling is the dominant way SIEMs pull logs, not an edge case, and treating it as a temporary workaround misreads the whole industry. Secureworks documents the practical version of this with Microsoft 365 log collection: ingestion runs on a schedule with deliberate lag built in to catch data that arrives late, and when the lag runs longer than expected, the recommended troubleshooting steps are to check the polling interval, check for Microsoft-side throttling, and check downstream indexing delay. All three of those are structural, not accidental. Nobody misconfigured anything. The system works exactly as designed, and the design has a hole in it.

The gaps that follow show up a few different ways. A source was never connected in the first place. A connection exists, but polling lag delays the data past the point where it can be correlated with whatever else happened at the same time. Cost pressure pushes a team to cut polling frequency, or drop a high-volume source entirely, because ingesting everything costs money and somebody has to choose what gets left out. The trade-off is well documented: more log volume costs more money, so enterprises pick which sources make the cut, and the excluded data becomes a blind spot by definition. CISA and the Australian Cyber Security Center issued joint guidance in May 2025 urging organizations to prioritize their highest-value log sources to speed up detection, which is really an admission that nobody can log everything, and the resulting gaps are just the price of the constraint.

Cloud environments show this clearly. An organization might have solid detection coverage on Windows endpoint privilege escalation and nothing meaningful watching AWS IAM role changes. The integration for the cloud control plane may exist on paper, fully configured, and still lag real-world activity by the full width of its polling interval. There's a cruel irony built into the pattern, too: the tools polling most aggressively, trying hardest to stay current, are the ones most likely to hit a rate limit and fall behind.

How coverage drift turns a working integration into a blind spot over time

An integration that works at deployment doesn't stay that way on its own. Coverage drift is the widening gap between what a stack is supposed to monitor and what it actually monitors, and it builds quietly, through no single decision anyone can point to later.

An API version changes upstream and the polling integration starts pulling partial data, or fails outright, and nobody notices right away. Analysts tune down alert sensitivity to cut through noise, and in the process strip out signal that used to cover a real attack path. The person who understood what an integration covered, and what it didn't, leaves the company, and that knowledge leaves with them. New cloud or SaaS tools go live, start generating logs, and never get connected to the SIEM because somebody assumed a connector already existed. The pattern is consistent: misconfigurations, new service rollouts, and unmanaged APIs in fast-changing infrastructure create fresh monitoring gaps on a rolling basis.

None of this requires a mistake, exactly. It's what happens by default when nobody's job is to notice. Roughly 40% of API integrations fail due to unhandled rate limits, and most of those failures are silent: the integration looks like it's running, while data quietly stops arriving or arrives incomplete. Worse, a tool that's stopped contributing any real signal still shows up as "active" in the security posture, still holds its permissions, still looks, on paper, like coverage. It just isn't, and the team that would need to notice the drop-off usually isn't the team that built the integration in the first place.

Why tool sprawl makes each of these problems worse rather than better

The instinct, once a gap gets found, is to buy something to cover it. That instinct is backwards. Adding tools to fix a polling gap usually adds more polling gaps than it closes, and the industry's own numbers back this up rather than just the intuition. Gartner's 2025 figures put the average security stack at 45 tools, and every one of those tools that polls another source is a fresh integration, with its own interval, its own rate-limit exposure, its own way of failing quietly.

The pattern runs the same way almost every time. A SOC 2 requirement lands, so a GRC platform gets added. The GRC platform doesn't scan cloud infrastructure, so a cloud scanner gets bolted on. The cloud scanner doesn't manage endpoints, so an MDM tool joins the stack. Each addition is reasonable in isolation. Together, they're a growing set of API relationships, any two of which can collide over the same rate limit, or drift out of sync with each other over time. Different vendors use incompatible data formats and inconsistent APIs, which keeps threat intelligence from reaching the tools that would actually act on it.

The consequence shows up in how breaches get discovered. A recurring pattern shows organizations frequently learn about their own breaches from an outside source, not from anything inside their own stack. That's not a coincidence, and it shouldn't be read as one. It's what a fragmented detection layer produces. Security professionals routinely report spending more time managing their tools than doing security work, which means the hours that should go toward watching for late-arriving events go instead toward keeping the tools that deliver those events running at all. WalkMe's 2025 research put the average enterprise loss from underused technology and stack complexity at $104 million in 2024. Research has found a meaningful share of security teams describe their own stacks as too complex to maintain well, which directly slows response to anything new. Every one of these numbers points the same direction: a bigger stack doesn't shrink blind spots, it multiplies the places they can form.

Why lean IT teams are the worst-positioned to catch what polling misses

A dedicated SOC has the headcount to watch integration health, notice when a source goes quiet, and dig into anomalies in the collection pipeline itself. Most small and mid-sized organizations have none of that. Lean IT teams end up managing tools instead of watching for threats, not by choice, but because keeping the integrations running consumes the time that would otherwise go to detection work.

Only about 10% of organizations have anything resembling an advanced governance strategy for API security, which leaves the remaining 90% without the systematic oversight that would catch silent throttling or slow coverage drift before it matters. In a lean environment, the specific things that go unnoticed follow a pattern: an integration that quietly stopped receiving data three weeks ago, two tools sharing API credentials and unknowingly competing for the same rate limit, a new cloud service that went live and was never wired into monitoring, a detection rule dialed back months ago that happened to be the one thing watching an attack path that's active right now.

Low-and-slow attacks are particularly dangerous here, because catching one means actively investigating what isn't firing, and that takes time nobody has spare. Polling lag doesn't send a notice. No tool tells the team it missed four minutes of activity. The team just never sees what happened in that window, and has no way to know to look. The dynamic compounds on itself: lean teams are the ones most likely running a fragmented, piecemeal stack, assembled one compliance requirement at a time, and least likely to have the staff hours to check whether all those pieces are actually talking to each other correctly. Zip, an all-in-one security platform for lean teams, is one option built around collapsing that stack before the gaps compound.

What a stack designed to avoid these failure modes looks like in practice

Shortening the polling interval helps at the margins, and that's all it does. It doesn't fix anything, because the fix has to be architectural, not a tuning knob. As long as polling is the collection pattern, there's a structural gap between when something happens and when a tool learns about it, and no amount of interval-shrinking closes a gap that's built into the pattern itself.

Webhooks are the right tool for anything time-sensitive, and treating them as optional is where most stacks get this wrong. Instead of a receiving system asking "anything new?" on a timer, the source pushes the event the moment it happens, and detection delay drops close to zero. Time-sensitive events belong on webhooks wherever the source supports it. Polling is fine for catalog updates and periodic reports, where a few minutes of lag costs nothing. Most of what a security stack needs to know falls into the webhook category, and most multi-tool stacks still poll for it anyway, because polling is easier to bolt onto an existing integration than building a proper push architecture.

Consolidation solves the problem more completely than either interval-tuning or webhook retrofitting, and it's the option worth choosing when it's on the table, not a fallback for teams that couldn't get webhooks working. When device management, identity, endpoint security, and compliance all run inside a single platform, data doesn't have to cross an API boundary on anyone's schedule to get correlated. It's already in the same place. There's no rate-limit collision between tools competing for the same budget, no polling interval creating a window an attacker can move inside, no coverage drift from an integration nobody's watched in months. The visibility gap that polling creates between tools doesn't narrow. It disappears, because there's no boundary left to poll across.

For organizations that can't consolidate immediately, the exposure is still manageable, if not eliminated. Audit every polling integration and its interval, and map the detection window each one creates. Find out which tools share API credentials and are quietly competing for the same rate limit. Push authentication, identity, and endpoint sources toward webhook collection wherever the vendor supports it. Treat pipeline health as a metric worth watching on its own: a data source going quiet should trigger an alert by design, not get discovered by accident long after the fact.

None of this is really about building a bigger stack with better-tuned intervals. It's about cutting the number of places where lag and rate limits turn into a blind spot. For a lean IT team especially, consolidation isn't a nice-to-have. It's the thing that gets the maintenance burden off their plate and hands back the hours that should have been going to detection all along.