Your labeling vendor is renting Microsoft’s quota. That’s why it breaks at Scale.
You've probably seen this without naming it.
Files land. Labels don't. By the time your sensitivity classifications catch up, the data's already moved, been shared, sat in someone's OneDrive for a day. Your labeling vendor swears the system's working. The audit log proves it. Jobs queued, jobs failed, jobs retried tomorrow.
Welcome to Microsoft Graph throttling. And it's not the only ceiling you're hitting.
The ceiling nobody put in the sales deck
Here's the part most labeling vendors don't talk about. Most labeling tools apply a Microsoft Information Protection label by calling Microsoft Graph, specifically the assignSensitivityLabel API. Graph is the API layer that fronts every Microsoft 365 service. It's also two things at once: rate-limited and metered.
The rate-limiting piece is well known. Microsoft caps how many requests any tenant can push through Graph in a given window. Those limits exist for good reasons. They keep one customer from melting the service for everyone else. But they don't care about your labeling program. If your file volume is bigger than the quota Microsoft hands you, the queue grows faster than your labeling drains it.
The metering piece is the part that surprises most teams. Microsoft classifies assignSensitivityLabel as a metered API. Every call is billed to the calling application's linked Azure subscription. As of Microsoft's current documentation, the rate is $0.00185 per call. That sounds like a rounding error until you do the math on a real environment. A million-file backfill is $1,850 in Microsoft API charges on top of whatever your labeling vendor costs you. Ten million files is $18,500. And that's only what Microsoft bills. It says nothing about whether the throttling lets the job finish.
This isn't a vendor defect. It's the architecture constraint every Graph-dependent tool runs into the moment its customer gets serious about labeling at scale.
The symptom is daily labeling that doesn't run daily.
The worst case is the most common one
The scenario that breaks the Graph path hardest is also the one most enterprises eventually need: applying a default sensitivity label across existing content.
The pattern is familiar. The compliance team decides every file in a given location should carry at least a baseline label. The CISO wants it done. The board wants it done. Overnight, the labeling tool has to write a label to millions of files that are already at rest.
For a Graph-dependent tool, this is the worst possible workload. It's a single burst of write calls hitting the same Graph quota, all at once. The throttling kicks in, the backfill stretches across weeks, and the metered cost stacks per call regardless of whether the job ever finishes. Some teams quietly give up on the baseline labeling program at this stage. Others run it on a long, partial schedule and accept the gap.
What Microsoft actually recommends for this
Here's the other thing the sales deck usually doesn't surface. The Graph assignSensitivityLabel API isn't the only path Microsoft documents. The Microsoft Information Protection SDK is Microsoft's documented path for native, third-party labeling at the host level. It's the SDK Microsoft itself built for applications that need to label files without going through the metered Graph API on every call.
So the architectural question isn't whether to label MIP files. It's how to label them.
What the architecture looks like when it isn't Graph
PK Protect labels MIP-protected files using the Microsoft Information Protection SDK, locally, on the host where the file lives. The agent on the endpoint or server applies the label directly. No per-file Graph call. Labeling speed isn't gated by Microsoft's quota, and the per-file metered cost goes away.
A few things follow.
Throughput scales with your endpoint footprint, not with Microsoft's rate limiter. If an agent runs on the host, the file gets labeled. The bottleneck moves from an API you don't control to compute you do.
The label travels with the file. Because the agent applies it at the host using the SDK, it's the same Microsoft-recognized sensitivity label any Purview-aware system downstream knows how to read and enforce. You're not building a parallel taxonomy. You're using Microsoft's, on Microsoft's terms, without renting Microsoft's quota per file.
The same control plane handles labeling and what comes after it. For a lot of customers the label is the deliverable, and that's a clean stopping point. For others, the label is the trigger for the next move: encrypt, redact, mask, quarantine, audit. Either way, it's the same agent and the same policy engine. No second tool to bolt on.
What this looks like in production
One of PKWARE's largest financial-services customers, running PK Protect Endpoint Manager across tens of thousands of endpoints, recently needed daily MIP labeling on .xlsx files landing in a specific target location. Their previous tool was calling Graph and hitting throttling limits every day. The business need was simple. The architecture wouldn't support it.
PKWARE stood up the POV in days, not weeks. Labels applied as expected, on the schedule the business actually needed, with a clear path to expand to local OneDrive next.
The same customer has been running PKWARE as their encryption backbone for over five years, protecting about a million files a day through the platform. The labeling capability fits the same architecture they already trust for encryption, which is part of why the POV came together fast.
A voice from the field
The compliance argument behind all of this is one Fiserv's security architecture team has made publicly. From the published Fiserv case study:
"Providing a mechanism to protect the data is definitely a key aspect… encryption is central to compliance, especially in financial services."
— Adam Coelho, Fiserv
That's the framing that matters here. Labeling is a compliance mechanism. When the mechanism stops working on schedule, it stops working as a compliance control.
What lagging labels actually cost
A label that doesn't run on schedule isn't a backlog. It's a control gap. The file moved through your environment unclassified. It was shared, opened, copied, attached, downloaded. By the time the label catches up, the audit question isn't "did you label this?" It's "where did this data go before you labeled it?"
In a regulated environment, that's not a queue problem. It's an exposure window. CMMC Phase 2 is enforcing sensitive-data identification later this year. PCI DSS 4.0.1 expects classification depth that holds up under assessment. The GLBA Safeguards Rule treats data inventory and protection as continuous, not periodic. None of those frameworks accept "the vendor was throttled" as a control exception.
And AI is making this faster. Agentic workflows are reading and writing files in volumes that human users never approached. The data labels are gating what those agents can touch. A label that's a day late is a permission that's a day wrong.
What to ask your current vendor
If you're already running an MIP labeling program, three questions are worth asking this quarter.
Does your product label MIP files by calling Microsoft Graph, or by using the MIP SDK on the host?
If the answer is Graph, the quota problem and the metered cost are in the architecture, not the configuration. Neither one is going away with tuning.
Who pays the Microsoft API charges?
If your vendor labels through Graph, the per-call cost is metered to your Azure subscription. Most teams don't see it until the Azure bill arrives.
At our file volume, can you guarantee daily labeling, and a baseline backfill, without throttling?
Watch the answer. If it includes phrases like "with proper tuning" or "we recommend a less aggressive cadence at scale," you've found the ceiling.
The takeaway
Done daily, labeling is invisible infrastructure. Skipped a day, it's an audit finding.
If your vendor is borrowing Microsoft's quota to label your files, you're not in control of when those skipped days happen. Microsoft is.
That's the architecture choice. It's worth asking who's making it for you.
See how PK Protect labels MIP-protected content at scale without per-file Graph calls.
You've probably seen this without naming it.
Files land. Labels don't. By the time your sensitivity classifications catch up, the data's already moved, been shared, sat in someone's OneDrive for a day. Your labeling vendor swears the system's working. The audit log proves it. Jobs queued, jobs failed, jobs retried tomorrow.
Welcome to Microsoft Graph throttling. And it's not the only ceiling you're hitting.
The ceiling nobody put in the sales deck
Here's the part most labeling vendors don't talk about. Most labeling tools apply a Microsoft Information Protection label by calling Microsoft Graph, specifically the assignSensitivityLabel API. Graph is the API layer that fronts every Microsoft 365 service. It's also two things at once: rate-limited and metered.
The rate-limiting piece is well known. Microsoft caps how many requests any tenant can push through Graph in a given window. Those limits exist for good reasons. They keep one customer from melting the service for everyone else. But they don't care about your labeling program. If your file volume is bigger than the quota Microsoft hands you, the queue grows faster than your labeling drains it.
The metering piece is the part that surprises most teams. Microsoft classifies assignSensitivityLabel as a metered API. Every call is billed to the calling application's linked Azure subscription. As of Microsoft's current documentation, the rate is $0.00185 per call. That sounds like a rounding error until you do the math on a real environment. A million-file backfill is $1,850 in Microsoft API charges on top of whatever your labeling vendor costs you. Ten million files is $18,500. And that's only what Microsoft bills. It says nothing about whether the throttling lets the job finish.
This isn't a vendor defect. It's the architecture constraint every Graph-dependent tool runs into the moment its customer gets serious about labeling at scale.
The symptom is daily labeling that doesn't run daily.
The worst case is the most common one
The scenario that breaks the Graph path hardest is also the one most enterprises eventually need: applying a default sensitivity label across existing content.
The pattern is familiar. The compliance team decides every file in a given location should carry at least a baseline label. The CISO wants it done. The board wants it done. Overnight, the labeling tool has to write a label to millions of files that are already at rest.
For a Graph-dependent tool, this is the worst possible workload. It's a single burst of write calls hitting the same Graph quota, all at once. The throttling kicks in, the backfill stretches across weeks, and the metered cost stacks per call regardless of whether the job ever finishes. Some teams quietly give up on the baseline labeling program at this stage. Others run it on a long, partial schedule and accept the gap.
What Microsoft actually recommends for this
Here's the other thing the sales deck usually doesn't surface. The Graph assignSensitivityLabel API isn't the only path Microsoft documents. The Microsoft Information Protection SDK is Microsoft's documented path for native, third-party labeling at the host level. It's the SDK Microsoft itself built for applications that need to label files without going through the metered Graph API on every call.
So the architectural question isn't whether to label MIP files. It's how to label them.
What the architecture looks like when it isn't Graph
PK Protect labels MIP-protected files using the Microsoft Information Protection SDK, locally, on the host where the file lives. The agent on the endpoint or server applies the label directly. No per-file Graph call. Labeling speed isn't gated by Microsoft's quota, and the per-file metered cost goes away.
A few things follow.
Throughput scales with your endpoint footprint, not with Microsoft's rate limiter. If an agent runs on the host, the file gets labeled. The bottleneck moves from an API you don't control to compute you do.
The label travels with the file. Because the agent applies it at the host using the SDK, it's the same Microsoft-recognized sensitivity label any Purview-aware system downstream knows how to read and enforce. You're not building a parallel taxonomy. You're using Microsoft's, on Microsoft's terms, without renting Microsoft's quota per file.
The same control plane handles labeling and what comes after it. For a lot of customers the label is the deliverable, and that's a clean stopping point. For others, the label is the trigger for the next move: encrypt, redact, mask, quarantine, audit. Either way, it's the same agent and the same policy engine. No second tool to bolt on.
What this looks like in production
One of PKWARE's largest financial-services customers, running PK Protect Endpoint Manager across tens of thousands of endpoints, recently needed daily MIP labeling on .xlsx files landing in a specific target location. Their previous tool was calling Graph and hitting throttling limits every day. The business need was simple. The architecture wouldn't support it.
PKWARE stood up the POV in days, not weeks. Labels applied as expected, on the schedule the business actually needed, with a clear path to expand to local OneDrive next.
The same customer has been running PKWARE as their encryption backbone for over five years, protecting about a million files a day through the platform. The labeling capability fits the same architecture they already trust for encryption, which is part of why the POV came together fast.
A voice from the field
The compliance argument behind all of this is one Fiserv's security architecture team has made publicly. From the published Fiserv case study:
"Providing a mechanism to protect the data is definitely a key aspect… encryption is central to compliance, especially in financial services."
— Adam Coelho, Fiserv
That's the framing that matters here. Labeling is a compliance mechanism. When the mechanism stops working on schedule, it stops working as a compliance control.
What lagging labels actually cost
A label that doesn't run on schedule isn't a backlog. It's a control gap. The file moved through your environment unclassified. It was shared, opened, copied, attached, downloaded. By the time the label catches up, the audit question isn't "did you label this?" It's "where did this data go before you labeled it?"
In a regulated environment, that's not a queue problem. It's an exposure window. CMMC Phase 2 is enforcing sensitive-data identification later this year. PCI DSS 4.0.1 expects classification depth that holds up under assessment. The GLBA Safeguards Rule treats data inventory and protection as continuous, not periodic. None of those frameworks accept "the vendor was throttled" as a control exception.
And AI is making this faster. Agentic workflows are reading and writing files in volumes that human users never approached. The data labels are gating what those agents can touch. A label that's a day late is a permission that's a day wrong.
What to ask your current vendor
If you're already running an MIP labeling program, three questions are worth asking this quarter.
Does your product label MIP files by calling Microsoft Graph, or by using the MIP SDK on the host?
If the answer is Graph, the quota problem and the metered cost are in the architecture, not the configuration. Neither one is going away with tuning.
Who pays the Microsoft API charges?
If your vendor labels through Graph, the per-call cost is metered to your Azure subscription. Most teams don't see it until the Azure bill arrives.
At our file volume, can you guarantee daily labeling, and a baseline backfill, without throttling?
Watch the answer. If it includes phrases like "with proper tuning" or "we recommend a less aggressive cadence at scale," you've found the ceiling.
The takeaway
Done daily, labeling is invisible infrastructure. Skipped a day, it's an audit finding.
If your vendor is borrowing Microsoft's quota to label your files, you're not in control of when those skipped days happen. Microsoft is.
That's the architecture choice. It's worth asking who's making it for you.
See how PK Protect labels MIP-protected content at scale without per-file Graph calls.