Executive Summary

  • Adrian Perrig is a professor of computer science at ETH Zurich, head of its Network Security Group, a principal architect of SCION, a co-founder of Anapaya Systems and chair of the SCION Association’s advisory board. These roles span research, commercial translation and ecosystem governance, but they do not make him a telecom-network operator or the controller of individual SCION deployments.
  • SCION reorganises inter-domain networking around isolation domains, cryptographically protected path information and path-aware forwarding. Its purpose is not to eliminate failure, but to make trust boundaries, route choices and failure containment more explicit than they are in the conventional BGP-centred internet.
  • The strongest evidence of operational relevance comes from Swiss deployments, especially the Secure Swiss Finance Network and related critical-infrastructure use. Public sources document production participation, while global traffic volumes, commercial revenue, contract details and comprehensive long-term performance data remain unavailable.
  • Perrig’s influence depends on collective adoption. Researchers can design an architecture, a company can productise it and an association can coordinate participants, but operators, customers, regulators and vendors decide whether the design becomes durable infrastructure.

A profile defined by an architectural problem

Adrian Perrig is best understood through the problem he has chosen to work on rather than through a conventional academic biography. The public internet routes traffic among thousands of independently operated networks. That independence supports resilience and competition, but it also means that no central authority can prescribe every path, remove every insecure practice or coordinate a clean replacement for protocols already embedded in routers, operating procedures and commercial relationships.

The Border Gateway Protocol remains the practical foundation of inter-domain reachability. It distributes route announcements and allows autonomous systems to apply local policy, yet it was not designed with the full security expectations later placed upon it. Route leaks, erroneous origin announcements, weakly authenticated information and the uneven deployment of protective mechanisms have therefore become persistent operational concerns. BGP works at extraordinary scale, but that success has created deep switching costs and a trust model that still depends heavily on filtering, operational convention and after-the-fact response.

Perrig’s work asks whether a different architecture can make those properties explicit. SCION—Scalability, Control and Isolation on Next-Generation Networks—does not assume that the current system can be patched indefinitely without structural compromise. It begins with a cleaner design: divide the global network into administratively meaningful trust regions, authenticate the control information used to construct paths, move more route choice towards endpoints and packet senders, and contain some failures within bounded domains.

That ambition explains both Perrig’s importance and the limits of a person-centred story. He helped originate and lead the architecture, but an architecture becomes infrastructure only when institutions agree to deploy, connect, operate and finance it. Any serious profile must therefore move repeatedly between individual contribution and collective execution.

From EPFL and Carnegie Mellon to secure-systems research

Perrig’s academic formation spans EPFL and Carnegie Mellon University. The supplied research records an undergraduate degree from EPFL, followed by master’s and doctoral work at Carnegie Mellon. He then served on the Carnegie Mellon faculty from 2002 to 2012 before moving to ETH Zurich in 2013, establishing a path from secure-systems research in the United States to a long-term institutional base in Switzerland.

The Carnegie Mellon period matters because SCION did not appear in an intellectual vacuum. Perrig’s wider work has covered network security, authentication, secure protocol design and systems intended to operate under adversarial conditions. Those interests are visible in SCION’s central choices: route construction is treated as a security problem as well as a connectivity problem, control information is cryptographically protected, and the architecture assumes that some organisations, links or components may fail or behave incorrectly.

Academic security research can demonstrate mechanisms under controlled conditions. Inter-domain routing imposes a harder test because a proposed mechanism must coexist with business relationships, hardware lifecycles, regulatory constraints, operational habits and an installed base that no laboratory can replace. Perrig’s later career can therefore be read as an attempt to close that gap through a research programme, a company capable of delivering products and support, and an association intended to distribute stewardship beyond one laboratory or vendor.

It would be an overstatement to claim that his education or early appointments predetermined SCION. Public records do not disclose every internal design discussion or motive. The defensible conclusion is narrower: his secure-systems background and academic leadership gave him the technical and organisational platform from which a clean-slate inter-domain architecture could be pursued over many years.

ETH Zurich became the institutional home of SCION

Perrig joined ETH Zurich in 2013 and leads its Network Security Group. ETH provides more than a faculty title. It gives SCION an institutional setting in which protocol design, formal reasoning, implementation, measurement, student training and industry collaboration can proceed together. Long-horizon infrastructure research rarely survives through papers alone; it needs teams, test environments, software maintenance, funding and continuity across successive generations of researchers.

The relationship between Perrig and ETH should nevertheless remain proportionate. Universities are collective institutions, and SCION has involved faculty colleagues, researchers, engineers, students and external collaborators. The published architecture and software are the result of that wider community, even where Perrig’s leadership is direct and well documented. Credit for originating and guiding the programme does not justify assigning every mechanism or implementation decision to him personally.

ETH’s location also shaped the deployment environment. Switzerland has dense financial, public-sector, research and telecom institutions with strong incentives to examine security and resilience. That does not mean the country automatically accepts a new routing architecture, but it does create identifiable sectors in which path control, jurisdictional awareness, availability and explicit trust relationships may justify experimentation and production investment.

The strongest account of Perrig’s role is therefore institutional rather than heroic. He built and sustained a research programme capable of moving across papers, prototypes, operational partnerships and commercial formation. Many clean-slate architectures remain influential as ideas but never develop a deployment ecosystem; SCION’s Swiss operational footprint shows that this programme crossed that boundary, even though its global scale remains limited and incompletely measured.

BGP’s durability strengthens the case for a clean-slate alternative

BGP’s shortcomings are often listed as if they prove that replacement should be straightforward. The opposite is true. Its durability shows how deeply a protocol can become embedded in infrastructure. Operators understand its failure modes, vendors implement it, monitoring systems interpret it, interconnection agreements depend on it and staff are trained to manage it. A new design must therefore compete not only with technical weaknesses, but also with an enormous stock of accumulated practice.

SCION’s clean-slate character is both its strength and its adoption burden. Starting again allows the design to integrate security and path awareness rather than bolt them on later. It can define trust domains deliberately, make cryptographic verification part of the normal control process and let senders choose among authorised paths rather than leaving every decision inside intermediate networks. Yet every departure from established practice adds transition work.

This trade-off is central to Perrig’s infrastructure relevance. He is not proposing only a stronger cryptographic primitive; he is proposing a different division of responsibility. In the conventional model, inter-domain path selection emerges mainly from routing announcements and policies applied by networks along the way. In SCION, control-plane information constructs authorised path segments, and the resulting forwarding path is carried in packet headers so that end systems or supporting services can choose among available routes.

That shift creates new possibilities and new duties. Applications and operators need path-selection policy, implementations must process and validate path information, administrators must understand isolation-domain governance, and monitoring systems must explain why one authorised path was selected over another. Perrig’s work matters because it makes these responsibilities visible rather than treating secure routing as a feature that can simply be switched on.

Isolation domains make trust boundaries explicit

One of SCION’s defining concepts is the isolation domain, usually abbreviated as ISD. An ISD groups autonomous systems around a common trust framework and a core that supports control-plane functions. The purpose is not to divide the internet into disconnected national or corporate islands, but to make the basis of trust explicit and to contain some control-plane failures or compromises within a defined scope.

This is a different starting point from a globally uniform trust assumption. Organisations already operate under different legal systems, commercial arrangements and security expectations, while conventional routing often hides those differences behind one reachability layer. SCION represents them architecturally. An ISD can publish the trust roots and policies relevant to its participants, while inter-ISD communication allows traffic to cross those boundaries.

The design has clear appeal for critical infrastructure. A financial network, public-sector environment or regulated industry may care not only that a destination is reachable, but also which domains a path traverses, which organisations participate in the trust chain and whether alternative routes are available. Isolation domains can support that reasoning without claiming that geographic or institutional boundaries are absolute.

The concept also carries governance risk. A trust domain can be well administered or poorly administered, and its membership rules can be transparent or exclusionary. Local control can improve accountability, but it can also create fragmentation if interfaces, policies or trust relationships diverge. SCION does not abolish governance; it relocates and formalises parts of it, requiring enough common structure for independently governed domains to interoperate.

Cryptographic path construction changes the security baseline

SCION’s control plane constructs path segments and protects them with cryptographic mechanisms. At a high level, networks disseminate information that allows authorised paths to be assembled. The data plane then carries path information in packets, enabling routers to forward according to the selected route without relying on conventional global route lookup at every hop in the same way as BGP/IP forwarding.

The cryptography matters because it makes unauthorised path manipulation harder and allows participants to verify that path information was produced within the expected control framework. It should not be interpreted as a guarantee against failure. Keys can be mishandled, software can contain defects, administrators can configure policies incorrectly, and legitimate networks can still suffer outages or congestion. Security properties remain bounded by implementation and operations.

The stronger claim is that SCION raises the cost of certain attacks and errors by changing what must be forged or compromised. It also gives endpoints and operators more information about the paths available to them, reducing dependence on opaque route propagation and making policy enforcement more deliberate.

For Perrig, this extends secure-systems reasoning to inter-domain infrastructure. A protocol should not rely solely on every participant behaving correctly; it should make important state verifiable and limit the damage that one compromised element can cause. SCION applies that principle at inter-domain scale while still depending on physical routers, fibre, power, software distribution and operator skill.

Path awareness transfers choice towards endpoints

Path-aware networking is another central SCION idea. Instead of presenting the sender with only a destination and allowing intermediate routing processes to determine the route invisibly, the architecture can expose several authorised paths. A sender, host service or network-policy system can then choose according to latency, disjointness, jurisdiction, cost, provider preference or other constraints.

This does not mean every end user will manually select a route. Most should not need to. Path awareness creates a control surface on which software, enterprises and service providers can express policy. A critical application might prefer two disjoint paths and fail over between them, while a regulated service might avoid a specified jurisdiction and a low-latency workload might move to another route when congestion changes.

The shift also changes power relationships. Networks still decide which path segments they advertise and under what commercial terms, but endpoints gain more visible choice among the authorised options. Application and platform operators may therefore gain influence because they can build path selection into service logic, while regulators may seek to define acceptable path policies for sensitive sectors.

The value of that choice depends on trustworthy information and usable tooling. Too many options without reliable metrics can make operations harder, and policies can conflict. A path that appears jurisdictionally attractive may perform poorly, while a path selected for disjointness may share hidden physical infrastructure. SCION enables more explicit decisions, but physical and organisational dependency data remain essential.

Multipath resilience depends on real diversity

SCION is often associated with resilience because it can expose several paths and support rapid switching. The mechanism is credible: if endpoints know several authorised routes, they can move traffic when one path degrades. That can reduce dependence on slow global reconvergence and give critical services more direct recovery options.

The practical benefit depends on diversity. Two logical paths may traverse different autonomous systems yet share the same fibre duct, power substation, colocation facility or upstream provider. Cryptographic path information cannot reveal every physical common cause, so operators still need topology knowledge, contractual information and measurement to decide whether alternatives are genuinely independent.

Resilience also depends on preparation. A backup route that has never carried production traffic may fail when needed, capacity may be insufficient, security policy may permit the primary path but block the alternate, and monitoring may not recognise partial degradation quickly enough. SCION can make failover more controllable, but operational discipline remains decisive.

The same caution applies to attack resistance. Path control can help route around some denial-of-service conditions, and isolation can limit certain control-plane failures, but a sufficiently large attack can still exhaust links or endpoints. The contribution is a more structured defence and recovery surface, not immunity.

SCION separates routing architecture from physical ownership

Perrig does not operate the telecom networks over which SCION traffic flows. The architecture depends on carriers, internet service providers, enterprise networks, data centres and exchange infrastructure that remain under their own ownership and control. Designing a routing system is not the same as operating the underlying network.

An architecture can define packet formats, trust relationships, control messages and path-selection mechanisms. It cannot compel an operator to install software, provision capacity or connect to another participant. Anapaya can sell products and support, the SCION Association can coordinate specifications and community work, and ETH can research and publish, but none can unilaterally convert global networks.

This layered dependence is one reason the Swiss deployments matter. They show organisations choosing to place the architecture into a real operating environment. The evidence is stronger than a laboratory prototype but narrower than universal adoption: it demonstrates that the system can be integrated with production requirements, not that every class of network has solved the transition problem.

The separation between architecture and ownership also affects accountability. When a SCION service fails, the cause may lie in software, local configuration, an underlying link, a provider contract or an application policy. Operators therefore need clear responsibility boundaries so that a new control plane does not become another way to obscure failures behind a multi-party stack.

Anapaya Systems translated research into a commercial operating model

Anapaya Systems was founded in 2017. Public material identifies Perrig as a co-founder alongside other ETH-linked founders, including David Basin, Peter Müller and Samuel Hitz. The company’s purpose is to turn SCION concepts and software into products, integration services and support that organisations can procure and operate.

Commercialisation changes the nature of the work. A research implementation can demonstrate an architecture, while a production vendor must manage releases, security updates, documentation, customer requirements, interoperability, support obligations and liability. It must fit into existing networks rather than assume a blank environment, and it must explain who operates each component and what happens when dependencies fail.

Perrig’s co-founder role connects him directly to this transition, but the company is not an extension of one person. Executives, engineers, investors, customers and partners shape product decisions. Public sources do not disclose every contract, revenue figure or internal allocation of authority, so it would be wrong to describe Perrig as personally controlling Anapaya’s operations or commercial outcomes.

Anapaya also introduces incentives that differ from academia. A company needs revenue and repeatable deployment, and may therefore prioritise features customers will buy, sectors with strong security requirements and partnerships capable of accelerating adoption. These incentives can strengthen implementation quality, but they can also create concerns about vendor dependence or proprietary concentration around an architecture presented as shared infrastructure.

The product layer is not identical to the protocol

SCION as an architecture, open-source codebase and community specification should be distinguished from Anapaya’s commercial products. The protocol defines interoperable behaviour and security mechanisms, while a vendor packages those mechanisms into deployable components, management systems, support and operational workflows.

This distinction is familiar in internet infrastructure but often blurred in profile writing. TCP is not an operating-system vendor, and BGP is not a router manufacturer. In the same way, SCION should not be reduced to Anapaya, even though Anapaya is a prominent route through which organisations obtain production capability.

The boundary creates a governance requirement. Participants need to know which parts of the stack are openly specified, which implementations are available, how compatibility is tested and whether data or configuration can move between suppliers. A healthy ecosystem can include commercial vendors without making one vendor the sole source of validity.

Perrig’s position spans both sides. As an academic architect, he has an interest in the integrity and evolution of the design; as a co-founder, he helped create a company whose success depends on adoption. The roles are compatible but not identical, and analysis should recognise the incentive tension rather than assume either pure public interest or purely commercial motive.

The Secure Swiss Finance Network provides the clearest production case

The Secure Swiss Finance Network, commonly known as SSFN, is the strongest publicly documented example of SCION’s operational relevance. SIX, the operator of key Swiss financial-market infrastructure, developed the network with telecom and technology partners to provide protected communication for financial institutions and connected service providers. Public announcements identify SCION as the architectural foundation.

The significance is not that the financial sector abandoned the public internet. SSFN is a specialised environment for participants that need controlled access, path assurance and resilience. It shows how a next-generation routing architecture may first gain adoption in bounded communities where the value of stronger trust and routing policy is high enough to justify transition costs.

SIX reported that production use had progressed sufficiently for the older Finance IPNet to be retired, with the transition completed in 2024. Later public material described more than one hundred connected participants and use extending beyond finance into areas such as education, healthcare, energy and payments. Those figures provide evidence of a real ecosystem, though they do not reveal traffic volumes, service-level performance or the share of each sector’s communications carried over SCION.

The SSFN case also demonstrates collective attribution. Perrig’s architecture is foundational, but SIX, Swisscom, Sunrise, SWITCH, Anapaya, participating institutions and their technical teams performed the deployment work. Regulators and sector requirements helped shape demand, so a person profile should connect Perrig to the architecture without converting a multi-institution programme into an individual achievement.

Critical-infrastructure adoption reflects specific incentives

Finance, energy, healthcare and public services have reasons to value SCION that differ from those of a consumer broadband provider. They may face stronger continuity requirements, regulatory scrutiny, contractual obligations and sensitivity to the jurisdictions or operators through which traffic passes. A path-aware system can turn those concerns into explicit technical policy.

Adoption is not automatic. Critical-infrastructure organisations are often conservative because failures carry high costs. They require procurement assurance, vendor support, integration testing and long maintenance horizons. Staff need training, incident-response teams need visibility, and existing applications and security controls must continue to work.

The Swiss experience suggests that adoption can proceed through a community with shared requirements and a coordinating institution. That model may be more realistic than asking unrelated networks to switch independently because it creates a bounded value proposition and a governance context in which trust roots, membership and service expectations can be agreed.

The same model can create concentration. If one coordinating organisation, vendor or telecom partner becomes indispensable, the system may replace one dependency with another. Critical users therefore need tested exit paths, alternative providers and clarity about who can change trust or routing policy.

The SCION Association marks a shift from project to ecosystem

The SCION Association was launched in 2023 as an organisation dedicated to the architecture’s development and adoption. Public records place Perrig in an advisory role and identify him as chair of the advisory board. The association brings together members from research, industry and operational communities.

Creating an association is a significant institutional step. Research projects can be guided by a principal investigator and companies directed through corporate governance, but shared infrastructure needs a forum in which participants coordinate specifications, software, events, deployment practices and representation without assuming that one founder remains the permanent decision maker.

The association’s existence does not by itself prove decentralised governance. The relevant questions concern membership diversity, voting and decision rights, technical-change processes, implementation conformance and the balance among vendors, operators and academic institutions. Advisory status can provide intellectual continuity, but operational legitimacy depends on broader participation.

Perrig’s chairmanship gives him visible influence without amounting to unilateral authority over members or deployments. Advice can shape priorities and interpretation, while boards, staff, working groups and participating organisations retain their own responsibilities. The move from project to association is therefore part of SCION’s infrastructure, not merely a communications exercise.

Governance is part of the architecture

SCION’s isolation domains make governance visible at the technical layer. Someone must decide which entities belong to a domain, which trust roots are accepted, how policies change and how participants respond to compromise. The architecture does not remove these decisions; it creates a structure in which they can be made locally and represented explicitly.

This has advantages. A domain can align responsibility with the organisations affected by its choices, update trust without waiting for universal agreement and set requirements appropriate to a sector or jurisdiction. Local failure need not redefine validity everywhere else.

It also creates risks. Membership can become a gatekeeping tool, trust rules can be opaque, domains can diverge in ways that raise interoperability costs, and powerful participants can influence policy beyond their formal role. Technical users may have little voice if governance is dominated by vendors or institutional sponsors.

Perrig’s public work emphasises security and path control, but those properties depend on governance quality. A cryptographically verifiable decision can still reflect poor policy. Verification shows that a rule was applied or a statement was authorised; it does not prove that the rule is legitimate. This distinction also aligns with Lu Heng’s infrastructure notes, which separate technical validity from institutional authority; the connection is analytical rather than evidence about SCION.

Sovereignty can mean choice without requiring isolation

SCION is frequently discussed in relation to digital sovereignty. The term is imprecise because it can refer to national control, data localisation, procurement independence or resilience against foreign dependency. SCION’s path and trust model can support some of these goals, but it does not dictate one political interpretation.

A government or regulated industry could use path policies to prefer routes through specified jurisdictions or trusted providers. An isolation domain could reflect a national or sectoral trust framework. Those capabilities can reduce exposure to unknown intermediaries and make dependency more visible.

The same mechanisms could be used to restrict connectivity or reinforce political control. Architecture does not decide whether sovereignty protects users, institutions or state authority; governance and law determine the application. A profile should therefore avoid presenting sovereignty as an automatically positive technical outcome.

The more defensible benefit is optionality. Participants can express route and trust preferences without requiring the entire world to adopt one policy, and inter-domain communication can continue across different local frameworks. Whether that balance survives at scale remains open, particularly if trust negotiation becomes complex or a small number of core domains emerge as gateways for most communication.

Transition costs are part of the security model

A secure design that cannot be deployed has limited infrastructure value. SCION must coexist with the conventional internet because operators cannot replace global routing in one coordinated event. Gateways, overlays, service-specific networks and incremental deployment therefore become part of the transition model.

Coexistence introduces complexity. Operators may need to maintain both SCION and IP/BGP paths, troubleshooting spans several control planes, security teams must understand where traffic crosses between architectures, and application developers may need libraries or services capable of using path-aware features while preserving fallback.

These costs can create security risk of their own. Dual systems enlarge the configuration surface, gateways can become bottlenecks or targets, and inconsistent policy may cause traffic to use a weaker fallback unexpectedly. Staff may also understand the established stack better than the new one.

The economic burden is uneven. A large financial institution can fund integration and testing, while a small network may not. Vendors and shared-service providers can reduce the cost, but they may also concentrate expertise and operational dependence. The Swiss deployments provide evidence of how bounded communities can move, but the wider cost curve remains unknown.

Open specifications and open-source implementation matter for exit

A path-aware architecture can promise choice while still becoming difficult to leave if software, management interfaces or operational knowledge are concentrated. Open specifications and open-source components are therefore part of the system’s long-term control structure rather than secondary benefits.

Participants need the ability to inspect protocol behaviour, test independent implementations and move configurations or policies without rebuilding the entire service. Vendors need stable interfaces on which to compete, researchers need access to evaluate security claims, and operators need tooling that does not disappear if one company changes direction.

Open source does not guarantee practical independence. A codebase can be open but too complex for most organisations to maintain, one vendor may employ the majority of experts, and certification or support requirements can still create lock-in. The useful measure is not the licence alone, but the existence of credible alternatives and shared competence.

The SCION Association can help by supporting documentation, conformance and community development. Universities can train engineers and test ideas, while commercial providers supply accountable support. A healthy ecosystem needs all three, and it should make decision processes visible enough that SCION’s promise of path choice is matched by institutional choice.

Standardisation is a continuing process

SCION has developed through academic publications, implementation work, operational collaboration and community specifications. Its path differs from that of a protocol that begins inside an established standards body and moves directly towards an RFC. That can speed experimentation, but it also raises questions about how independent review and interoperability are organised.

A specification becomes shared infrastructure when different organisations can implement it consistently, security assumptions are challenged and changes are governed predictably. Publication is necessary but not sufficient. Test suites, deployment experience, vulnerability response and version compatibility create the real standard over time.

Perrig’s relation to the wider internet-standards community is therefore contextual. SCION addresses the same inter-domain environment in which IETF protocols operate, but its institutional development has centred on ETH, Anapaya, deployment partners and the SCION Association. Linking the profile to the broader protocol ecosystem should not be read as a claim that the IETF owns or directs SCION.

The important monitoring question is whether SCION’s technical and governance processes become legible to organisations outside the founding network. Independent implementations, public change records and participation by diverse operators would strengthen confidence, while dependence on a narrow group would limit the claim that the architecture can serve as a general alternative. The preference for a stable common minimum, with local decisions above it, also echoes Lu Heng’s infrastructure framework, although that connection is analytical rather than evidence of SCION’s design intent.

Research evidence is stronger than global-impact evidence

SCION is extensively documented as an architecture. Papers and project materials explain isolation domains, path construction, cryptographic mechanisms and forwarding. Public deployment announcements establish that organisations use it in production. These are meaningful forms of evidence.

Important gaps remain. Public sources do not provide a comprehensive measure of global SCION traffic, the number of autonomous systems carrying it, revenue generated by related products, detailed contract terms or independent long-term comparisons across diverse networks. Even the Swiss figures describe participants rather than the volume or criticality of every service.

This gap does not invalidate the project, because infrastructure adoption is often commercially sensitive and difficult to measure. It does mean that claims should remain bounded. “Deployed in critical infrastructure” is supported, while “replacing BGP globally” is not. “Designed for stronger path assurance” is supported, while “eliminates routing attacks” is not.

The distinction is especially important in a founder profile, where architectural vision can attract celebratory language. Perrig’s most defensible achievement is not global conversion, but the sustained movement of a technically coherent alternative from research into multi-organisation production. The next stage requires evidence about scale, diversity, operational cost and governance performance.

Security assessment must include implementation and operations

A secure architecture can fail through ordinary engineering. Memory-safety defects, key-management mistakes, insecure update systems, weak access controls and monitoring gaps can undermine protocol properties. SCION’s cryptographic design reduces some classes of uncertainty, but it does not exempt implementations from this reality.

Production users need vulnerability disclosure, patch distribution, dependency management and incident coordination. They also need to know whether a flaw affects one vendor product, an open-source component or the protocol itself, and they need fallback plans that do not silently abandon the security policy the deployment was intended to enforce.

The association and vendor ecosystem therefore carry a continuing obligation. Research publication explains the model, but operational security requires maintenance. The speed and transparency of response to future defects will be a stronger test than broad claims about secure-by-design architecture.

Perrig’s academic authority can help establish a rigorous culture, but it should not substitute for independent review. External researchers, competing implementations and production operators can reveal assumptions that a founding team misses. A mature ecosystem invites that scrutiny and provides enough evidence for users to evaluate the response.

Route-choice optimisation shows the programme is still evolving

ETH public material in 2026 described continuing work on route-choice optimisation supported by a European Research Council project. The development matters because path awareness creates a new optimisation problem. Once several paths are visible, a system must decide which route best satisfies performance, security, cost and policy constraints.

This work indicates that SCION is not a frozen protocol awaiting adoption. The research programme continues to examine how applications and networks can use the control surface effectively. That is a strength because operational experience should inform evolution, but it is also a governance challenge because changes must preserve compatibility and avoid giving sophisticated platforms an unfair advantage over smaller participants.

Route optimisation can improve performance and resilience, yet the objective function matters. A platform optimising latency may concentrate traffic on one provider, a company optimising cost may reduce diversity, a regulator optimising jurisdiction may increase path length, and a security policy may conflict with service quality.

The value of path awareness is that these trade-offs can be expressed. The risk is that they become hidden inside proprietary selection algorithms. Operators and users therefore need enough transparency to understand why traffic moved and which constraints were applied.

Perrig’s influence is broad but indirect

Perrig has direct authority within his academic group and documented leadership over the SCION research programme. As a co-founder, he helped establish Anapaya, and as advisory-board chair he can influence the association’s strategic and technical discussion. These are substantial roles.

He does not operate the carriers, banks, hospitals, energy companies or public networks that may use SCION. He does not set their procurement policy or routing configuration, and he cannot compel vendors to implement the architecture or customers to renew contracts. He also does not manage the DNS root, internet exchanges or cloud platforms merely because SCION interacts with those layers.

His impact mechanism is therefore sequential. Research defines an architecture, software and commercial products make it deployable, partners integrate it with physical networks and services, an association coordinates shared development, and operators decide whether to adopt it. Regulators and customers shape the incentive environment around the entire chain.

Influence can be strongest at the beginning of that sequence and weaker at the end. Perrig can frame the problem and propose mechanisms, but he cannot guarantee market scale or operational quality. This bounded description is more useful than a heroic one because it shows where his influence can be observed and where evidence must come from others.

The infrastructure impact mechanism

Perrig’s infrastructure impact can be described through seven linked stages. Secure-systems research established a foundation for treating routing information and trust as verifiable state. The SCION programme converted those principles into a coherent inter-domain architecture, and ETH provided continuity, research capacity and implementation work.

Anapaya then turned the architecture into products and services that organisations could buy. Swiss financial and critical-infrastructure deployments supplied operational proof, while the SCION Association created an ecosystem institution. Ongoing research and deployment feedback continue to shape path selection, optimisation and governance.

Each stage changes the kind of authority involved. Academic authorship is intellectual, company formation adds executive and commercial responsibility, product deployment adds contractual and operational accountability, and association work adds collective governance. None can substitute for the others.

The chain also explains why attribution must remain collective. Perrig is the central connecting figure, but the outcome depends on co-authors, co-founders, engineers, operators, financial institutions, telecom providers, public bodies and users. The mechanism is not proof of inevitable scale; it is a map of how scale could occur if products remain reliable, governance broadens and independent implementations grow.

SCION and incremental routing-security improvements address different problems

SCION should not be evaluated as though the only alternative were an unprotected version of BGP. The existing internet has developed incremental protections, including route-origin authorisation through the Resource Public Key Infrastructure, route filtering, monitoring, operator coordination and emerging work on validating more of the autonomous-system path. These mechanisms can improve security without replacing the basic inter-domain architecture, although deployment remains incomplete and each covers only part of the problem.

The comparison clarifies SCION’s proposition. RPKI-based origin validation can help a network determine whether the origin AS announcing a prefix is authorised by the resource holder. It does not normally expose several end-to-end paths to an application, provide packet-carried forwarding paths or organise trust through SCION-style isolation domains. Filtering and monitoring can reduce risk, but they often rely on operator action and may detect problems only after an announcement has propagated.

SCION integrates a different trust and path model from the beginning. That architectural coherence can provide stronger properties, but it raises the transition threshold. An operator can add route-origin validation to an existing BGP environment without asking customers and counterparties to use a new packet architecture, whereas joining a SCION ecosystem requires new control-plane and forwarding capability, policy integration and relationships with other SCION-connected participants.

The relevant question is therefore not whether SCION is better in the abstract, but whether its additional control and assurance justify the organisational change for a given service. Critical networks may answer yes because the cost of uncertainty is high, while general-purpose access networks may prefer incremental protection because ubiquity and compatibility dominate. The approaches can coexist, and each should be judged against the layer of routing risk it is designed to address.

Why BTW tracks Adrian Perrig

BTW tracks Perrig because his career provides a rare view of infrastructure change across four layers: research, protocol architecture, commercial translation and ecosystem governance. He is not simply a professor who published a clean-slate design, nor simply a founder selling security products. He is a figure through whom the attempt to make an alternative inter-domain architecture durable can be examined.

SCION matters to digital infrastructure because it challenges assumptions embedded in conventional routing. It makes trust boundaries explicit, exposes path choice and attempts to contain failures. These are not abstract features when governments and critical industries are reconsidering jurisdiction, concentration and resilience.

The architecture also reveals the limits of technical solutions. Trust domains need legitimate governance, several paths need real physical diversity, cryptographic assurances need secure implementations, and commercial deployment needs exit options. A system designed to reduce hidden dependency can create new dependencies if its ecosystem narrows.

Perrig should therefore be monitored neither as the inventor who will replace the internet nor as an academic whose work is detached from operations. The evidence supports a more consequential middle position: he has led an architecture from research into bounded production, and the institutions around it are now testing whether stronger path control can scale without sacrificing openness and plural control.

Principal evidence and unresolved questions

The principal evidence base for this profile consists of ETH Zurich faculty and project records, Anapaya’s corporate history, SCION Association publications, SIX announcements about the Secure Swiss Finance Network and the supplied subject-specific research pack. These sources establish roles, dates, architectural concepts and documented deployments.

They do not provide complete insight into commercial contracts, revenues, traffic volumes, customer configuration, incident history or the internal decision rights of Anapaya and the association. Company and association statements are evidence of official position, not independent proof of every performance claim.

The unresolved questions are operational. How many independent networks use SCION for material production traffic? How diverse are the implementations and suppliers? How quickly can domains recover from a trust or software compromise, and what does coexistence cost over a decade? Do path choices remain transparent to customers, and can participants change vendors or governance domains without disruptive migration?

Those questions define the next phase of the story. Perrig’s architecture has moved beyond theory, but its global role remains open. The decisive evidence will come from independent adoption, operational performance, governance under stress and the ability of users to retain real choice as the ecosystem grows.