Quantum computing is beginning to move from labs into commercial deployment, and one of the main ways companies will be able to access this technology is through Quantum-as-a-Service (QaaS) offerings.  Instead of companies investing in costly quantum hardware on-site, the QaaS model would allow them to tap into quantum capabilities via remote access services, much like they would with Software-as-a-Service (SaaS) arrangements. But while the delivery model may be akin to the SaaS model, quantum technology is still in its early stages and has unique hardware and infrastructure related challenges, as further described in a recent Covington blog post. 

In addition to the points in the original Covington blog post, below are some additional points to consider when negotiating QaaS agreements:

1. SLAs:  Expectations around Service Level Agreements (SLAs) may prove to be another thorny area in QaaS contracting. While customers may seek to apply traditional SaaS uptime standards (e.g., 99.9% availability), quantum computing systems may not yet be capable of delivering such high levels of availability.  As such, there may be a push in QaaS contracting for more shared risk around the infrastructural and environmental challenges that are unique to quantum computing.

2. Support Obligations: Support obligations would deviate from what we typically see in the context of SaaS agreements; instead support obligations in quantum will include hardware-related support.

3. Pricing:  Customers may look for predictable pricing and request that the pricing decrease as quantum systems mature and become less expensive to operate. On the other hand, service providers are likely to push for flexibility to raise prices, given the significant uncertainties and expenses associated with maintaining hardware that is so cost-intensive and space-intensive. 

4. Cybersecurity Risks in Hybrid Systems:  Cybersecurity remains a risk when it comes to hybrid systems in quantum computing offerings – although QaaS providers may use quantum computers as the hardware, it is expected that such providers may still make use of classical computing systems for storage and processing of customer data.  Because the classical computing systems that QaaS providers use could be using current encryption standards (such as RSA or ECC), customers may reasonably worry about long-term exposure of their sensitive data once it is shared with and stored by the QaaS service provider in their classical systems. For this reason, customers may press providers to adopt post-quantum or quantum-safe cryptography standards for components that use classical computing, or at least to commit to a roadmap for doing so after the relevant standards, guidance, and best practices are in effect. Service providers, however, may resist any firm obligations given that quantum-safe approaches are still evolving and can introduce interoperability or performance issues. Relatedly, given the unique risks here, customers may seek tighter incident response terms and audit rights.

5. Export Controls: Both service providers and customers will want to be attentive to export controls applicable to the hardware, software, and related technology used to deliver the QaaS offering, as well to any export controls applicable to technologies developed using QaaS.  Even domestic access to a system by a foreign national can constitute an export. Service providers may seek assurances from customers regarding the access and end use of the technologies or data produced using QaaS and may need to limit access to export controlled infrastructure.  Service providers may also request exit provisions in the event customers become subject to export restrictions in the future. Customers may seek to restrict the geographies in which their data is stored or request assurances that the infrastructure used to provide the QaaS is compliant with U.S. export control laws and regulations. 

The above considerations establish that QaaS agreements present issues and considerations that differ from SaaS or other technology services contracts. Given that quantum computing is both technically complex and rapidly evolving, careful drafting that reflects a practical understanding of the underlying technology and its capabilities will be critical. In certain cases, parties may also consider vested contracting, which is a collaborative contracting framework where parties align on shared goals and outcomes.  By anticipating the pace of innovation and embedding flexibility into contractual terms, parties can work towards ensuring that their QaaS agreements remain both effective and sustainable as the technology and field continues to mature.

Another general issue in QaaS contracting centers around appropriately allocating evolving compliance costs and risks. Because legal and regulatory frameworks for quantum computing are still developing (e.g., cybersecurity standards and export controls, as described above), ensuring the service provider’s compliance with established standards will require ongoing consideration, investment, and adaptation. Contracting parties should therefore clarify who bears the related costs and obligations, and consider mechanisms such as cost-sharing provisions or governance committees that are tasked with revisiting and establishing compliance requirements as they evolve. In this regard, the collaborative nature of vested contracting can also prove beneficial, allowing the parties to treat regulatory adaptation as a shared challenge and overall outcome rather than a unilateral burden.

Please feel free to reach out to the authors with any questions.  We would be happy to further discuss this guidance or provide legal support on your next quantum computing project.

Lisa Ann Johnson contributed to the “Export Controls” section of this blog post.