The per-asset pricing trap
The platform's job is to find assets you didn't know you had. Every asset it finds adds to your bill.
Enterprise security teams have been caught by usage-based pricing models before, like when cloud compute bills balloon because a workload scales unexpectedly or SIEM costs explode when log volume triples after a new data source is added. The per-asset daily pricing model used by some EASM platforms creates the same dynamic, with one specific twist that makes it harder to anticipate: the platform's job is to find assets you didn't know you had, and every asset it finds adds to your bill.
The mechanism is straightforward. You model your contract costs against your known asset inventory: the servers, cloud instances, and domains your team has documented. The platform then does what it was designed to do: seedless discovery maps infrastructure you didn't declare, including forgotten subdomains, shadow IT deployed by development teams outside the security perimeter, infrastructure inherited from acquisitions that was never fully inventoried, and cloud instances spun up and abandoned without deregistration. Each of those discovered assets is metered. Your bill reflects the actual size of your attack surface, not the size of the attack surface you thought you had when you signed.
For organizations with stable, well-understood infrastructure, this is not a problem. If your asset footprint is predictable and your IT governance is tight, per-asset daily pricing can be cheaper than flat platform licensing. The volatility problem is specific to environments where those conditions don't hold: active DevOps teams spinning up cloud infrastructure continuously, significant M&A activity that keeps absorbing new infrastructure, or a history of decentralized IT that has left shadow assets distributed across the environment. These are also exactly the environments where EASM delivers the most value, which is the structural irony — the organizations that most need continuous external discovery are the ones whose costs under a usage-based model are hardest to predict.
What gets missed in the contract negotiation
The asset count used in initial contract pricing almost always comes from the buyer's internal records: their CMDB, their cloud asset register, their DNS inventory. These records are the system of record for assets the organization knows about. They are not a reliable input for pricing a platform whose primary value is finding the assets the organization doesn't know about.
A security team that signs a per-asset daily contract based on a known inventory of 5,000 assets and then discovers their actual external footprint is 12,000 assets — including forgotten infrastructure from a three-year-old acquisition and a collection of development subdomains that were never decommissioned — has a budget problem that begins the moment the platform works correctly. The discovery run that justified the purchase is also the event that invalidates the cost model.
This is not a vendor transparency failure. The pricing structure is disclosed. The issue is that buyers are pricing contracts against the wrong input because the right input — the actual size of their external attack surface — is not known until after the platform runs.
The pre-purchase test
The specific mitigation is to get an asset count estimate before signing that reflects what the platform will actually discover, not what your internal records show. Most EASM vendors will run a scoped proof-of-concept or discovery sample before contract execution. The output of that exercise is the right input for cost modeling.
- What is the asset count from a seedless discovery run against our environment, not from our declared asset list?
- How does that count change when subsidiary domains and recently acquired infrastructure are included?
- What is the daily rate at that count, and what does a 50% increase in discovered assets do to the monthly bill?
- Is there a cap on metered assets, or does cost scale linearly with discovery?
If the vendor is unwilling to run a discovery sample before contract execution, that unwillingness is itself information about how the conversation will go when the bill arrives higher than expected.
The broader principle
Microsoft Defender EASM is the most prominent platform using per-asset daily pricing at enterprise scale, which is why it appears most frequently in this conversation. But the dynamic applies to any EASM contract where costs are tied to discovered asset count rather than a flat platform fee. As the market moves toward continuous discovery and away from point-in-time scanning, more vendors are experimenting with usage-based pricing models. The principle is the same regardless of which platform is on the table: price the contract against what the platform will find, not against what you already know.
The organizations most exposed to this dynamic are the ones with the most to gain from the platform. That is the trap.