The DAS Decision: Software and Security Matter as Much as Hardware
Modern DAS infrastructure is defined by software as well as hardware. Buyers should understand how software is maintained, how system access is controlled and how security is managed throughout the operational life of the network.
A Distributed Antenna System is highly visible as physical infrastructure. Remote units, head-end equipment, fibre connections and antennas all play an essential role in delivering mobile coverage and capacity. Behind that hardware, however, software increasingly influences how the system is configured, monitored, maintained and developed.
This means that software management and cybersecurity should form part of the DAS procurement process from the beginning. They should not be treated as separate considerations once the equipment has been installed.
Understand who is responsible
Before selecting a DAS platform, buyers should understand which organisation is responsible for its software and how that responsibility will be maintained throughout the product lifecycle.
The important question is not simply whether every element has been developed internally. Technology providers may work with specialist partners or incorporate third-party components within their systems. What matters is whether there is clear accountability.
Buyers should establish:
Who is responsible for maintaining the platform software?
Who controls the release of updates and security patches?
How are software changes developed, reviewed and tested?
Which elements rely on third-party technology?
How are third-party vulnerabilities monitored and addressed?
How long will software support remain available?
Who should customers contact if a software or security issue arises?
Responsibilities should be clearly defined before deployment. Customers should not have to determine who owns an issue after it has affected a live network.
Security is an ongoing process
Cybersecurity cannot be reduced to a single feature, certificate or statement made during procurement. Threats, vulnerabilities and accepted security practices continue to evolve. The security of a platform therefore depends on the processes used to manage it throughout its operational life.
Buyers should ask how potential vulnerabilities are identified, assessed and prioritised. They should also understand how customers will be notified when relevant issues arise and how updates or mitigations will be provided.
A credible approach should address:
Vulnerability monitoring and assessment
Software-update and patch-management processes
Testing before updates are released
Customer notification and technical guidance
System-access controls
User permissions and account management
Security logging and monitoring
Remote-access arrangements
Support for software throughout the product lifecycle
No connected system can be described as entirely free from risk. The more meaningful consideration is whether appropriate processes, expertise and accountability are in place to manage that risk.
A timely example of security accountability
The critical PHP vulnerabilities disclosed on 21 October 2026 provide a timely example of why software visibility and clearly defined security processes matter. CVE-2026-109618 and CVE-2026-109619 affect certain PHP environments and can potentially allow unauthenticated remote code execution. The disclosure required organisations to determine quickly whether PHP formed part of their products or supporting environments, assess any exposure and provide clear guidance to customers.
Following the disclosure, SOLiD conducted an internal technical review and communicated its findings directly to relevant customers.
This type of response is an important part of responsible lifecycle management. When a significant vulnerability is announced, customers need their technology provider to be able to establish:
Whether the affected technology is present within the solution
Which products and versions, if any, are affected
Whether an update, mitigation or configuration change is required
What immediate actions customers should take
How further developments will be monitored and communicated
Where a vulnerability does not apply, customers need that confirmation just as clearly as they need remediation guidance when action is required. The incident also demonstrates why organisations must maintain an accurate understanding of the software components and dependencies within their platforms. Without that visibility, it becomes far more difficult to assess exposure quickly and provide customers with a confident response.
Access should be controlled
DAS platforms may provide remote monitoring, diagnostics and management capabilities. These functions can help technical teams identify issues, assess performance and support customers more efficiently.
They must also be managed appropriately. Buyers should understand who can access the system, how users are authenticated and whether permissions can be allocated according to individual roles. They should also establish how access is removed when it is no longer required and whether important system activity can be recorded and reviewed.
Remote access should follow clearly defined procedures. Convenience should not come at the expense of appropriate control or accountability. The required approach will vary between projects. A commercial building, transport network, healthcare environment or major public venue may each have different security policies and operational requirements. These requirements should be considered during system design rather than introduced after commissioning.
Plan for software throughout the network’s life
A DAS may remain in operation for many years. During that time, operating environments, network requirements and security expectations may change. Buyers should therefore consider the long-term software path alongside the initial hardware specification.
Questions worth asking include:
How frequently is platform software reviewed and updated?
How will customers be informed when new releases become available?
What support is provided when an update is required?
Can updates be implemented without unnecessary disruption?
How are older software versions managed?
What happens when software reaches the end of its supported life?
How does the software roadmap align with the wider product roadmap?
The answers can help buyers assess whether the platform has a credible plan for continued maintenance and development.
Software forms part of long-term value
Initial equipment cost remains an important part of any procurement decision, but the ability to manage and support the platform securely also contributes to its long-term value. Software that is actively maintained, supported by clear processes and backed by experienced technical teams can help protect performance and operational continuity. Unclear ownership or limited long-term support can introduce uncertainty long after the original purchase has been completed.
Modern DAS infrastructure should therefore be evaluated as a combination of hardware, software, support and lifecycle management.
At SOLiD, we believe buyers should have a clear understanding of how their platform software will be managed, updated and supported—and who will remain accountable throughout the life of the network.
