Every other IT service provider asks us the same question: How does your tool help us scan black boxes in our datacenters?
The honest answer: I don't know! We can't scan black boxes because if we could, they wouldn't be black boxes anymore.
Due to the agreements you have signed with vendors such as Microsoft, you are generally not permitted to have black boxes, especially if your business model is based on the SPLA licensing model. You are contractually obliged to have access to all servers in your datacenter in order to determine the correct licenses.
I know that this answer doesn't get us anywhere; black boxes are a reality for many service providers, and there may be historical, technical, and process-related reasons for this. Whatever the reasons may be, black boxes pose a major risk to your business and can lead to high audit penalties, which can be unpleasant. What can we do about it, and how can we counteract it?
But let's start from the beginning.
What exactly are black boxes?
To stay compliant with the Microsoft Services Provider License Agreement (SPLA), your monthly reports and ability to pass an audit depend on a single factor: having clear, proven data regarding exactly what software was used. "Black boxes”, or data blind spots, completely undermine this requirement.
It is a mistake to think a "black box" is just a customer’s Virtual Machine (VM) that you cannot technically access. The term also applies to your own internal methods. If your reporting software counts licenses but cannot prove where that number came from, or if you lack a recorded history of changes, that is a black box. Furthermore, if you are manually guessing your usage based on sales numbers rather than technical evidence, you are creating a major compliance risk.
Colloquially, however, when service providers talk about black boxes, they usually mean areas of their IT infrastructure where the use, provision, or licensing of software cannot be tracked, verified, or documented.
Why does it matter?
SPLA agreements are based on a consumption-based model. Service providers must accurately report their monthly usage of Microsoft products and pay according to the extent of their deployment to customers. This model requires complete transparency and honest reporting.
Black boxes undermine this foundation in several ways:
- They cause gaps in reporting. If you cannot see what is being used, you cannot generate accurate reports. This means that you either underreport (violation of compliance rules) or overreport (you pay for licenses you may not even need and may end up charging your customers less).
- They represent a loss of control. If you don't know what's going on in your environment, you can't make informed decisions about licensing strategies, cost optimization, or security measures.
- They signal weak corporate governance to auditors. Even if you are technically compliant, the presence of black boxes indicates inadequate processes and controls, which may lead to closer scrutiny.
Microsoft conducts regular SPLA audits, and black boxes are your biggest vulnerability during these reviews. The consequences can be severe, with financial risks at the top of the list. If an audit uncovers unreported usage in your black boxes, you can expect to pay back for all those licenses, often retroactively for several years.
But let's forget about the auditors for a moment. With black boxes, you could also lose revenue from your customers, and there is a risk that they will run suspicious applications on your infrastructure, which also serves other customers and could affect them as well. Do you really want this situation?
How can black box risks be minimized?
There are many approaches to risk minimization. Here are the four that I consider most important:
- Talk to your customers
In most cases, the technical aspects and processes can be designed so that there are no black boxes. However, your customers do not want their rented virtual machines to be tracked in your shared infrastructure. You need to explain the obligations under the SPLA agreement to them and make it clear that you must comply with the license terms. Octopus Cloud can help you with this by offering various deployment options and strategies.
For example, your customer can take complete control of the collectors (agents), deploy them on the computers themselves, and forward the collected data to you after verification or send it directly to the Octopus Cloud platform. This ensures that no critical credentials are disclosed.
If your customer refuses to grant you access, and there is no way to track the VMs at the customer's site, you must agree with them that, in the event of an audit, any penalties imposed due to the customer's environment will be billed to them. This is the last possibility to secure yourself contractually.
- Train your teams
Ensure that everyone who uses Microsoft products understands the SPLA requirements and the importance of accurate tracking. Make compliance part of your corporate culture, not just a matter for the finance or legal departments.
- Conduct regular internal audits
Don't wait for Microsoft to audit you; conduct internal compliance audits at least once a year, comparing your deployed licenses with your SPLA reports. Consider this an opportunity to identify and close gaps before they become problems.
- Implement software asset management tools
Deploy automated asset discovery and software inventory solutions that continuously scan your entire environment. That’s a must and a foundation!
However, if you are operating in an SPLA environment, I can say with great conviction that we have developed one of the leading, if not the leading, platforms for this purpose.
We are the world's first SPLA tool to be assessed by KPMG. KPMG has thoroughly tested our solution and confirmed that all data is collected and calculated in accordance with the SPUR. Many of our customers also confirm that, when using Octopus, auditors do not run their own scripts and trust the data provided by Octopus.
Even though we cannot eliminate black boxes (no tool can), our tool can compare discovered data with inventory data from hypervisor and network scans to identify discrepancies and risks, which most SAM tools are unable to do.
In addition, our data collectors can be deployed agent-based or agent-less in customer environments, and in most cases, your customers can be convinced to deploy our data collectors in these black boxes without having to disclose sensitive data that is not relevant for the license calculation reports.
If you would like to learn more about how we can help you minimize your black box risks, I look forward to hearing from you so that we can show you the many possibilities in a demo.
Cihan Gökgöz, CTO of Octopus Cloud
