Sealing Daily Authentication Counts

When a SPLA audit arrives, the question is never what you reported last month. It is whether you can prove that what you reported was right, for every month going back three years. A Big Four firm conducts the audit under the MBSA audit clause with authority to request deployment records, server configuration data, customer contracts, and usage logs. The hoster who can produce a clean, contemporaneous daily record of who authenticated against each licensed product is in a completely different position from the one reconstructing usage from memory. That record is the sealed daily authentication count, and building the habit of keeping one is the most practical defensive move a hoster can make before any audit is on the horizon.

What a daily authentication count actually is

SPLA is pay as you consume. Each month a hoster applies the Services Provider Use Rights, the SPUR, and reports either Subscriber Access License counts, usually shortened to SAL, or processor counts for the products delivered to external customers. The SAL number is meant to reflect the unique users who had access to a licensed product. A daily authentication count is the underlying evidence for that number: a daily record, per product, of the distinct identities that authenticated against the licensed workload. Rolled up across the month, it produces the SAL figure you report. Kept daily, it gives you a defensible audit trail rather than a single end of month estimate.

Why sealing the count matters as much as capturing it

Capturing a daily count is only half the work. A number that can be edited later is a number an auditor can question, and a number you cannot explain. Sealing means fixing each day's count in a form that cannot be quietly changed after the fact, with the date it was recorded and the source system it came from. A sealed record carries weight precisely because it was created before there was any incentive to shape it. When you can show that the count for a given day was sealed on that day, the auditor is reading evidence, not an assertion. That is the difference between anchoring your position and defending a reconstruction.

Sealing does not require anything exotic. It requires that the daily figure is written to a record that is timestamped, attributed to its source, and retained unchanged. The discipline is in doing it every day, automatically, so that no month depends on someone remembering to run a report.

What to capture each day

A daily authentication count is only as useful as the detail behind it. The headline number matters, but so does the ability to break it down when an auditor questions a spike or a customer disputes a charge. Capture and seal the following for each licensed product, every day:

• The distinct authenticated identities for each licensed product, counted once per user per day
• The customer each identity maps to, so the count can be split by customer on demand
• The product version and edition in use, so the right SPUR obligation is applied
• The source system the count came from, named so it can be reproduced
• The date and time the count was sealed, fixed and unchangeable thereafter

Those five fields turn a bare total into a record that can answer a follow up question without a scramble. When an auditor asks why one product shows a higher count in a particular week, you can show the customer and the version behind the change rather than guessing.

A worked illustration of the monthly roll up

The figures below are indicative and chosen only to show how daily counts build a defensible SAL number, not to quote any real outcome. Picture one product over a short reporting window.

Indicative illustration of how sealed daily counts roll up into a defensible monthly SAL figure, not a quoted outcome.

The reported SAL is the count of unique users across the whole month, not the sum of daily figures, because a user who appears on several days is still one Subscriber Access License. The sealed daily detail is what lets you prove that the monthly number was derived correctly, and what lets you reconcile it back if the auditor reconstructs consumption a different way.

How the daily count protects you in an audit

In a SPLA audit the consumption figure drives everything. Back fees at the price file rate are calculated on whatever consumption the auditor reconstructs, and those back fees are not negotiable. On top of them sits the penalty uplift, which ranges from 25 to 125 percent depending on severity, duration, and the nature of any under reporting, and that uplift is negotiable. A sealed daily authentication count helps on both fronts. It keeps the reconstructed consumption honest, because you can show the real distinct user counts rather than letting the auditor infer a higher number from raw logs. And it characterizes any genuine shortfall as a narrow, documented matter rather than a pattern, which is the strongest argument for settling the uplift at the low end of the band.

Where the daily count fits in the wider defense

Sealing daily counts is one pillar of reporting discipline, not the whole structure. It works alongside customer mapping, product version mapping, and documented multi tenant boundaries to form a monthly reconciliation that holds up. For how the governance around these records survives scrutiny, see hoster governance that survives a Big Four audit, and for the boundary question that often determines who should be counted at all, read documenting multi tenant isolation for hosters. Each of these feeds the same posture set out in the pillar guide.

The next step

If you are not sealing a daily authentication count today, your monthly SAL numbers rest on end of month estimates that an auditor can question line by line. The SPLA Audit Defense Guide sets out the full reconciliation that a Big Four auditor will test your reporting against, including how to capture and seal these counts so they hold up across the 36 month lookback.

If an auditor is already asking questions, we take over the process through our Microsoft audit defense engagement.