IonQ–Elisity Agreement: Network Permissions and Quantum-Era Cryptography

Permissions and cryptography meet inside the enterprise

Selling quantum technology into an enterprise network requires more than an explanation of cryptographic strength. It requires a place in the everyday process of deciding who can connect to which business resource. The agreement makes that connection a concrete corporate-strategy question. SG Group puts the ability to join permission management and cryptographic management through shared information at the centre of its assessment.

IonQ’s agreement to acquire Elisity caps stock consideration at $1.3b including up to $150m earnout. A 20-trading-day volume-weighted average price (VWAP) before the third business day preceding closing sets shares. Conditional closing is expected Q4 2026; cryptographic inventory integration remains a roadmap.^[1]

The connection could have a practical benefit. Managing access to a server holding important information and managing the cryptography used by its connections in separate inventories creates work to reconcile the same target. If both records demonstrably refer to the same business resource, the enterprise can consider cryptographic changes and connection permissions together. Putting the inventories on one screen, however, does not establish that the reconciliation is correct.

This distinction also affects spending. If network, application and cryptography teams have to find their targets again whenever a technology is added, work accumulates beyond the purchase price. Reusing a system that links a target to its responsible owner could reduce that effort. The business attraction of the agreement lies in a design that reduces this specific work. A sales presentation displaying products together cannot establish the benefit.

Three defences answer different questions

Zero Trust rejects implicit trust based on being inside a network and requires authentication and authorisation for access to resources. The US National Institute of Standards and Technology (NIST) describes this approach in its 2020 publication. Post-quantum cryptography, or PQC, uses algorithms on conventional computers; NIST finalised three key-establishment and signature standards in 2024. Those standards’ establishment dates are separate from the latest corporate announcement.^[2][3]

Connection permissions, cryptographic algorithms and key distribution have different roles. A correctly authenticated employee may still have permission to read confidential information unrelated to their job. Appropriate permissions do not remove the task of updating cryptographic algorithms for future threats. Stronger key distribution cannot deliver the intended protection if the application using the key identifies its counterpart incorrectly. Ranking all three on one scale of strength obscures these differences.

Consider a hypothetical payment process using encrypted connections. Cryptography addresses the danger of someone reading content in transit. Whether the employee reviewing an invoice should also have permission to execute payment is a question of business permissions. Protecting the contents of a connection and deciding which actions its user can perform require separate decisions in this example. It illustrates the roles; it is not a customer case from either company.

The evaluation of an integrated product becomes more concrete when the questions are separated. Who decides permission to connect? Where are cryptographic changes made? What becomes unavailable if the equipment distributing keys stops? A proposal that identifies the owner and failure behaviour for each function is easier to compare than a general claim of quantum resilience. Buyers choosing separate products can also specify which function each alternative replaces.

What execution on an existing network entails

Elisity’s technical documentation separates cloud-based policy management from enforcement on supported existing equipment. It draws endpoint information from multiple sources and defines connection permissions using attributes such as users and devices. This is the vendor’s description of its existing product architecture, not evidence that the post-acquisition cryptographic functions are already connected throughout it.^[4]

In an architecture separating management and enforcement, having the correct policy on the management screen and delivering that policy to the actual equipment require separate checks. If old settings remain on a device after permission is revoked on the screen, the display and connection behaviour diverge. Conversely, a policy can reach the equipment yet restrict the wrong endpoint if the information identifying its target is incorrect.

For buyers, using existing infrastructure could reduce replacement work. The benefit nevertheless depends on the equipment and software on which the proposal actually operates. If it supports branches but not the location running a core business process, two management methods remain. Comparing it with wholesale equipment replacement requires considering operations during coexistence, as well as the purchase price.

This affects competition between products. Broader use on existing equipment could allow enterprises to choose functionality without waiting for an infrastructure refresh. Embedding business rules deeply in a particular connection method, however, creates work to transfer those rules when the enterprise changes products later. Ease of adoption and ease of replacement are different qualities. Export formats for settings and target inventories deserve a place in the commercial discussion.

Related reading: Build technology or partner for it

Identifying the same endpoint: IdentityGraph and freshness

IdentityGraph’s documentation describes matching information through IP addresses indicating network addresses, MAC addresses identifying network interfaces, and hostnames, alongside source priorities and manual settings. Last-seen and last-update times are separate fields. These features show that a decision sits between collecting information and selecting the value used in an operational rule.^[5]

The appearance of the same name is insufficient when joining cryptographic inventory. Imagine an enterprise with test and production environments using the same hostname. Joining cryptographic findings by name alone could leave someone believing production had been updated while they were reading a test-environment record. Business affiliation, location and other attributes may be needed to establish that the records concern the same target.

Time differences matter too. An endpoint can appear on the network today while its ownership information remains unchanged from last month. That does not necessarily identify the current responsible person. Conversely, recently updated attributes do not establish that the endpoint is currently connected. Selecting a person to request a cryptographic change should not collapse connection status and attribute freshness into one date.

SG Group emphasises a design that exposes disagreements rather than hiding them. If two sources identify different owners, the chosen value and the reason for choosing it should remain visible. If the relationship between an algorithm and an endpoint is uncertain, it should not count towards completed updates. Omitting these steps can produce fast-looking progress without explaining which resources have actually been protected.

Turning an inventory into a business change plan

NIST’s migration support addresses locating quantum-vulnerable cryptography and testing interoperability with other equipment and software. Identifying an algorithm does not complete migration. Work must proceed to the service using it, its counterparts, and the people responsible for deciding changes.^[6]

Imagine an enterprise with services receiving orders, managing inventory and processing payments. Changing cryptography only on the first service cannot keep the process connected if its counterpart cannot support the change. Mapping the connections from order to payment before treating each device as the unit of change helps identify intermediate parties. This map must be built for each enterprise; the announcement does not establish a customer’s configuration.

Permission-management information could provide a starting point. Knowing which services normally connect can help select pairings to test after a cryptographic change. An allowed connection is not necessarily used routinely, however. Paths used only for month-end processing or disaster contingencies may be absent from ordinary observation. Input from the business owner remains necessary.

Importance alone cannot determine the sequence of changes. The need to protect long-lived information, counterpart readiness and available maintenance windows vary. A connection to a trading partner that is not ready cannot necessarily be changed all at once, even if the enterprise itself is prepared. A shared inventory is useful when it connects these constraints to one target and explains the resulting sequence.

A hardware matrix defines the deployment boundary

Elisity’s hardware matrix distinguishes hosting a control function from enforcing connection policies. Recommended software differs by model, and some entries have not been validated by Elisity. Inclusion in the matrix cannot be extended to mean operation on every version or in every role.^[7]

These are deployment conditions that precede cryptographic technology. Suppose branches use supported models while factories use others. A common policy may not be enforceable everywhere at once. The enterprise might deploy first in branches and retain another method in factories. Its management view then needs to show where the same controls actually reach. A single “deployed” label cannot identify the remaining scope.

Avoiding hardware replacement may still require software upgrades, business downtime and compatibility checks. An upgrade could affect another monitoring function, so testing only the newly installed feature is insufficient. Checking coexistence with routine functions in an environment close to the actual infrastructure can reduce later changes. The matrix helps determine what belongs in those tests.

This boundary also belongs in sales explanations. Presenting broad support can help a sales discussion, but discovering an unsupported area later leaves the customer with additional design work. Specifying tested models, versions and roles does not weaken an explanation. It gives buyers information they can apply to their infrastructure and establishes conditions for comparing deployment estimates.

Which connections would use QKD?

Quantum key distribution, or QKD, concerns delivering keys. The US National Security Agency’s (NSA) public position, scoped to US National Security Systems, identifies issues involving specialised equipment, authentication, trusted relays, implementation and denial of service. It is neither a blanket prohibition for civilian enterprises nor a rejection specific to this agreement. The page does not establish a new policy-announcement date.^[8]

A QKD proposal should begin by defining the connections involved. Compare a hypothetical link between two fixed sites with connections made by travelling employees from many locations. Equipment placement and management of counterparts differ. Rather than assume one product name covers both, specifying what is added to which path makes the design constraints easier to identify.

Choosing a dedicated path also requires contractual treatment of counterpart verification and failure procedures. If the ordinary path is unavailable, does the business stop or switch to another protection method? Who authorises that switch? What connection records remain during it? Product introductions alone cannot settle these questions; both information sensitivity and the need to keep the business operating inform the decision.

Presenting PQC and QKD as interchangeable choices needs care. Changing an algorithm and adding key-distribution equipment involve different purchases, maintenance responsibilities and coordination with counterparts. The choice should not turn on novelty or the word “quantum”. Defining the necessary roles for each path allows comparison of plans using multiple methods and plans omitting a particular method.

Related reading: AI cyber capabilities and defence work

Shared inventories can change service-sector work

Technical integration could change work done by implementation partners and auditors outside the enterprise. Reusing a target inventory instead of rebuilding it could shift effort from counting equipment towards verifying the relationship between business processes and connections. This is an economic transmission path conditional on usable shared information, not a prediction that the acquisition immediately changes the market.

Poor inventory quality can produce the opposite result. If several functions use the same erroneous information, tracing and correcting the error can become a broader task. Integration may reduce management screens yet increase business disruption if permissions and cryptographic changes are applied to the wrong target together. The benefit of shared information and the danger of shared errors arise at the same connection point.

For cross-border enterprises, a common policy does not create a common implementation sequence. Maintenance windows, trading partners and infrastructure plans differ by site. A model of central requirements and local testing needs a division of responsibility: what the centre owns and what requires local approval. An integrated screen does not determine that division.

Economic effects emerge through this implementation and change work. Demand for specialists, equipment upgrades and partner-connection tests could rise, while reuse of work could reduce enterprise burdens. Which effect dominates depends on actual coverage and reusable information. Growing revenue for quantum-related companies and less work across enterprises are separate outcomes to follow.

Buyers need contractual responsibility, not just feature counts

Buyers can recognise the benefit of a single supplier while checking its responsibility boundary. A connection failure after an algorithm change and a failure caused by an incorrect permission setting may require different investigative teams. Even under one product name, identifying the support contact, the correcting team and the person deciding restoration gives the customer somewhere to begin during an incident.

Acceptance tests should also separate the functions involved. Blocking a prohibited connection, keeping a necessary business process running and communicating with a counterpart after a cryptographic change are distinct conditions. A claim of overall success does not specify which was tested. Keeping target-specific results, rather than merging all conditions into one score, makes them useful for later changes.

Renewal discussions should include whether inventories and rules can move to another product. Data exports still leave work if the rules interpreting the data reside only inside the original product. Priorities for choosing an endpoint’s attributes, for example, may not appear in a simple field list. Buyers should examine exportable information, the meaning of its settings and the manual work that remains together.

Deeper post-acquisition links make this reading of the contract more important. They can reduce routine work while increasing preparation for a future product change. Buyers compare convenience alongside the room to change later. Asking competitors the same questions turns an integrated approach and a multi-supplier approach into a comparison of specific tasks.

A reference-price band changes how share counts respond

To understand the stock consideration, take hypothetical fixed consideration C and divide it by reference share price V adjusted into the stated band: C÷min(49.61,max(33.07,V)). This reference calculation illustrates the disclosed mechanism. It does not determine final consideration, earnout payment details or the actual shares issued.^[1]

The chart fixes C at an illustrative $1b. At a $30 reference price it produces about 30.24m shares; at $40, 25m; and at $55, about 20.16m. For reference prices below the lower limit or above the upper limit, the lower and upper denominator limits apply, so further reference-price changes leave this hypothetical share count unchanged. The $1b is a convenient amount for comparing share counts, not a statement of the transaction’s base consideration.

The shape shows that shares and reference prices do not continue responding in the same proportion. Inside the band, a higher reference price reduces the shares corresponding to fixed consideration. Outside it, the denominator becomes fixed. The market value of the shares does not thereby become fixed. The share count received and the market’s valuation of those shares cannot be represented by the same line; this distinction is specific to reading the consideration mechanism.

An averaging-period price is also different from a single day’s traded price. Trading days and business days need not use identical calendars, and the averaging window cannot be fixed before the closing date is determined. Substituting one price from a market update and treating the share count as settled confuses the time basis. Market participants face the question of which period is referenced as well as the level of prices.

Technology expectations and corporate valuation evidence

The agreement offers two different subjects for assessment: connecting technologies and using shares as consideration. The first asks whether a design joining enterprise permissions and cryptographic management can actually be used. The second asks which share count follows from the contractual terms. Neither the share count alone determines technological merit nor attractive technology removes the need to read the consideration terms.

Projecting revenue growth directly from a technical announcement is difficult. If a customer receives a connection feature within an existing contract, more use does not equal more fees. If target-specific configuration and testing are sold separately, more deployment work need not become a recurring product. The unit sold changes the commercial meaning of the same technology.

Investors can specify evidence that follows this design. Has a product linking cryptographic inventories to connection targets been delivered? Are supported equipment and roles identified? What did customers contract for, and which tasks did they replace? Such information makes the sales audience and product scope clearer than simply adding quantum and cybersecurity markets together. The announcement cannot yield an unevidenced market share or share-price target.

Technical and financial evidence complement each other but are not substitutes. Successful connection tests require separate evidence of pricing and sustained use. Growing sales require a breakdown to attribute the increase to this integration. Post-acquisition disclosures should connect changes in the product to financial figures. A historical company-wide growth rate cannot simply be transferred to a new product’s performance.

Related reading: Using equity valuation ratios

The case for not rushing integration

One counterargument favours keeping products separate. Independently managing permissions and cryptographic changes could limit the spread of an error from one function to another. It also allows separate product choices without relying on one supplier’s decisions. Separation brings management work, but that work can sometimes provide an independent check.

A response is to divide integration into smaller steps. Initially share target information while retaining separate approvals for permissions and cryptographic changes. Automate repeated tasks after information reconciliation becomes stable. The convenience of a single view does not require combining every change authority at once. A design allowing the customer to choose its depth of integration provides a way to test this counterargument.

Another counterargument warns against excessive spending on quantum preparation. With no single settled date for the future threat, updating every device at once can waste effort. A response is to distinguish information needing long-term protection, connections that take time to change and connections that can be changed quickly. The idea is to sequence preparation from current business needs rather than predict a particular future day.

Enterprises also face problems beyond cryptography. Prioritising new algorithms while neglecting permission errors, endpoint management and business continuity weakens the connection to what needs protection. Integration has value when it links cryptographic preparation to these everyday responsibilities. The relevant question is whether spending on a new technology supports existing management or merely creates another management item.

Related reading: Cybersecurity demand and business performance

Three pathways and the evidence that changes an assessment

The first pathway achieves stable target reconciliation and allows permitted connections to guide cryptographic changes. Enterprises could reduce repeated searches for the same resource. Evidence supporting this view consists of product behaviour joining actual targets and tests comparing business operations before and after changes. A combined sales presentation cannot establish information reuse.

The second pathway connects functions but leaves equipment or counterpart coverage limited, requiring prolonged coexistence of operating methods. Convenience in one deployment area may not simplify the whole system. Additions to support matrices, remaining migration targets and coexisting procedures provide evidence of this pathway. The assessment depends on how remaining methods change, as well as on claims of adding targets.

The third pathway leaves information disagreements or responsibility divisions unresolved and confines benefits to a narrow area. Customers might choose separate functions. That choice is not a failure of all the technologies. If deeper integration adds more verification and correction work than it removes, its commercial attraction weakens. An explanation tied to targets and business processes is needed to understand why.

There is no basis for assigning probabilities to these pathways. Instead, define observations that change the assessment: information on target-matching accuracy, identified enforcement equipment and contractual responsibility boundaries. Following agreement-specific evidence in sequence makes it easier to revise expectations than allocating an entire market’s sales using hypothetical percentages.

What the next disclosures should clarify

Future company documentation should explain how cryptographic information joins existing targets. Which services, keys, certificates and algorithms belong to which resource? When information conflicts, what is updated and who approves it? Implementation detail at this level helps enterprises apply the design to their own configurations and consider deployment scope.

Deployment explanations should also specify when temporary permission is revoked. If an unusual connection is allowed for migration work and its setting remains afterwards, an exception becomes part of routine operations. Expiry dates and revocation following an owner’s completion approval require different tasks. Identifying who records the reason and end of an exception allows assessment of management after repeated changes, as well as initial deployment.

Transaction disclosures should establish closing, any changed conditions and the extent to which earnout criteria are explained. A clearly specified reference calculation cannot replace actual payment provisions. Once the relevant averaging window is determined, calculation can follow the conditions at that time. One share-price increase or decline cannot by itself assess both technical integration and contractual progress.

Customer documentation matters too. Beyond supplier descriptions, identifying the business process, changes made and procedures retained connects technology to routine operations. General satisfaction or customer counts make the specific effect of joining cryptography and permissions difficult to see. Comparisons aligning the differences between targets help other enterprises identify what would be useful for them.

SG Group View: beyond selling together, identify the same resource

SG Group reads the agreement as an attempt to connect quantum-related technologies to enterprise communication management. Once permissions, algorithms and key distribution are separated by function, correct use of shared targets could turn preparation into concrete change plans. The value emerges in repeated target-finding work that can be removed, rather than in market sizes created by adding technology names together.

Shared-information designs also concentrate responsibility. Without explanations of target-matching errors, paths retaining stale information and procedures for stopping changes, the convenience of unified management can run ahead of its safeguards. Customer choice over integration depth, exportable results and role-specific tests are conditions for assessing commercial strength.

Behaviour when management does not respond also affects integration quality. If a permission-checking service is unavailable, blocking connections can prioritise confidentiality but interrupt necessary work. Continuing with the last permission can help continuity while leaving old authorisation in place until revocation arrives. Selecting behaviour for each business process and specifying who is notified are concrete choices beyond the product name.

Ultimately, evidence should connect authorised counterparts, cryptography-using connections and enforcement equipment to the same business process. That lets enterprises decide where to deploy and where to retain another method. The reference-price band remains a separate tool for understanding consideration. Both technology and transaction should be followed at the level of the relevant target and time period.

FAQ

Sources and references

1. IonQ — Elisity agreement and transaction terms · 2026-10-12
2. NIST — SP 800-207: Zero Trust Architecture, abstract · 2020-08
3. NIST — Post-quantum cryptography · Standard establishment: August 2024
4. Elisity — Microsegmentation architecture · Page date unspecified
5. Elisity — IdentityGraph · Page date unspecified
6. NIST NCCoE — PQC migration: discovery and interoperability · Page date unspecified
7. Elisity — Hardware Compatibility Matrix · Page date unspecified
8. NSA — QKD and National Security Systems · Page date unspecified

Undated technical pages: as of 2026-10-13 JST. Hypothetical business diagrams are not company deployment results. The share-count chart uses fixed hypothetical consideration, not a price forecast or final payment.