Internet routing security is advancing, but publishing an authorization, checking a route and protecting a user's connection are different achievements.
The number that needs a second question
Published ROA object counts at year-end 2024 and 2025, from Snijders’s February 2026 APNIC report using RPKIViews snapshots. Not a filtering rate or count of protected users.
A growing count of signed routing authorizations is good news for the Internet. It means more address holders have published information that other networks can use to check certain routing claims. But the count does not say whether every network consults that information, whether its policies act on the answer or whether a particular user's connection is protected along the route it actually takes. The next question after “How much is signed?” is “What changes because it is signed?”
A February 20, 2026 review published on APNIC's blog provides a concrete example. Job Snijders compared end-of-year RPKI snapshots and reported 280,692 Route Origin Authorizations in 2024 and 344,209 in 2025. The report also counted validated payloads separately: 639,900 and 787,737. These are historical observations about published authorization data, not a measurement of today's worldwide filtering rate or a count of users whose traffic is secure. Snijders, RPKI's 2025 year in review.
The distinction is not a criticism of the measurement. It is the condition for using the measurement honestly. A database can grow while important gaps remain in enforcement. Enforcement can improve in strategically important places without producing a proportionate change in the database's size. Different measures illuminate different parts of the system.
RPKI, the Resource Public Key Infrastructure, is best understood as an important piece of a routing-security architecture rather than a universal certificate that the Internet is safe. This article follows the chain from an address holder's statement to a network's decision, then asks what evidence a customer, operator or public-interest observer should request. The operational scenarios are original fictional examples, not reports of incidents or instructions for manipulating other people's networks.
The Internet does not have one routing office
The Internet connects networks operated by different organizations. Each makes decisions about which routes it learns, accepts and advertises. That distributed arrangement is part of the system's flexibility, but it creates a difficult trust problem: one network receives claims about reachability from another, often without a direct relationship with the organization responsible for the destination's addresses.
NIST's June 2019 practice guide describes a demonstration platform using RPKI-based route origin validation to mitigate some routing misconfigurations and malicious route-hijacking behavior. Its stated scope is deliberately narrower than making all routing trustworthy. The guide concerns an example security architecture, not a claim that every operator has deployed it or that its historical product examples remain current recommendations. NIST SP 1800-14.
For a non-specialist, the essential distinction is between a destination and a claim about how to reach it. A website may be functioning perfectly while some users cannot reach it because their networks select an unsuitable path. Conversely, a successful connection does not prove that every underlying routing claim was properly authorized. Application behavior and routing control are related, but neither provides a complete diagnosis of the other.
This is why routing security deserves attention outside network engineering. A public service can depend on decisions made by several independently managed networks. Its own staff may control the application and hosting arrangement but not every policy between a resident and the service. A useful accountability conversation identifies those boundaries. It does not demand that a single supplier promise control over the entire Internet, and it does not accept those boundaries as an excuse for refusing to describe the supplier's own responsibilities.
What the authorization actually says
The RPKI architecture described in RFC 6480 links resource certificates to the allocation hierarchy for Internet address space and autonomous-system numbers. One application lets an address holder authorize particular autonomous systems to originate routes for that space. The document is an informational architecture published in February 2012, not a newly issued 2026 standard. Its enduring relevance is the separation between authority over a resource and a claim to originate a route involving that resource. RFC 6480.
A Route Origin Authorization, or ROA, is one signed object in that architecture. RFC 9582, published in May 2024 and replacing RFC 6482, specifies its profile. The authorization identifies an autonomous system and address prefixes, with an optional limit governing more-specific prefixes. If that optional limit is absent, the authorization applies to the exact listed prefix. The object is not a signature on every packet or on the complete path that a packet will follow. RFC 9582.
An original analogy is useful if kept narrow. Imagine a venue publishing a verifiable statement that a named organization may announce access to a particular entrance. The statement helps another party check the announced authority. It does not establish that every road toward the entrance is unobstructed, that every intermediary behaves honestly or that the event inside the venue is legitimate. Those are separate questions.
For public communication, the practical rule is to preserve the object of the assurance. An authorization about route origination should not become a claim about content authenticity, application security or uninterrupted availability. Narrow assurance is still valuable. It becomes misleading only when its boundaries disappear from the story.
Three states, not a moral verdict
Origin validation compares a route's prefix and claimed origin with validated authorization payloads. RFC 6811 defines three outcomes. A route is Valid when at least one covering payload matches the required origin and length conditions; Invalid when a covering payload exists but none matches; and NotFound when no payload covers the route. The document explicitly places complete path attestation outside its scope. Later clarifications must be read alongside this January 2013 specification. RFC 6811.
The words can mislead when carried into ordinary language. Invalid does not establish malicious intent. It can expose a mismatch that arose through an error or an incomplete change. NotFound does not prove legitimacy, and it is not the same as Invalid. Valid does not mean the entire connection is trustworthy. These are interpretations of the defined categories, not additional promises hidden inside their names.
Consider a fictional regional archive that moves its public service to another network. The new routing announcement may be legitimate in organizational intent while the published authorization still reflects the old arrangement. A validating observer can identify the mismatch without knowing the archive's migration plan. That is useful evidence of a coordination problem, but it is not a complete account of who made the error or whether anybody acted deceptively.
The archive's response should therefore investigate both the intended arrangement and the observed data. Publicly accusing an unfamiliar network of hijacking solely because an Invalid label appears would outrun the evidence. Ignoring the label because the migration was authorized internally would make the opposite mistake. The mismatch is a reason to reconcile the records and behavior, not a substitute for that reconciliation.
Publishing and filtering are separate commitments
An organization can publish accurate authorizations for its own address space without filtering the routes it receives. Another can perform origin validation on received routes while some address holders have published no relevant authorizations. These actions complement one another, but neither implies the other. A deployment statement that says only “we use RPKI” leaves an important ambiguity unresolved.
RFC 8481, published in September 2018, clarifies the distinction between setting validation state and applying routing policy. It addresses which prefixes are evaluated and makes clear that policy should not be applied without operator configuration. The point for this article is not to reproduce implementation instructions. It is that calculating a category and deciding what to do with that category are separate stages. RFC 8481.
The fictional archive can translate this into two supplier questions. What authorizations are maintained for the service's announced address space? Separately, what validation and policy are applied to received routes within the supplier's stated scope? The answer should name that scope rather than imply universal behavior across every device, relationship and address family.
This separation also helps interpret progress reports. A team may complete the publication work first because it has authority over its own resources. It may then test received-route policy in a controlled environment before expanding it. That staged progress can be responsible. Reporting the first stage as completion of both stages would not be.
A meaningful commitment describes the action, its boundary and the evidence that it continues to operate. The strongest wording is not necessarily the broadest wording. A precise statement about a defined network function is more useful than a sweeping assurance that cannot be checked.
The validator is a dependency, not invisible magic
The signed objects do not become routing decisions by themselves. A relying-party system collects and validates data, and routers obtain information they can use. RFC 8210 specifies version one of the RPKI-to-Router protocol, published in September 2017, for delivering relevant data from a trusted cache. This is a description of the protocol's role and dated version, not a recommendation to deploy a particular product or an assertion that protocol support proves a secure installation. RFC 8210.
The operational implications are familiar from other distributed systems. A correct decision depends on the data available at the point of decision. Two components can be healthy in isolation while the connection between them is stale or incomplete. A dashboard that reports a running process may therefore be insufficient evidence that the intended routing policy is using the expected information.
For the fictional archive, the useful supplier discussion concerns observable dependencies. How does the operator know whether validation data are being refreshed? How are discrepancies investigated? Which team owns the service that supplies the data? What behavior is expected during a loss of that service? These are governance and assurance questions, not a demand for public disclosure of sensitive configurations.
A dependency map should identify which failures are independent and which share a common cause. Two nominally separate components may rely on the same network path, administrative account or update process. Counting them as two does not automatically establish resilience. The relevant evidence is whether the arrangement can continue to perform its intended role under the failures the operator has chosen to address.
Time changes the answer
Routing announcements and authorization data can change independently. A route that has not changed can acquire a different validation state because the authorization data changed. A route can also change while the relevant authorization remains the same. Understanding an incident requires a timeline of both, not just a screenshot of whichever dashboard was easiest to capture.
RFC 9324, published in December 2022, updates RFC 8481 and addresses reevaluation after new RPKI data arrive. It discusses retaining relevant route information so a router can reconsider decisions without imposing unnecessary refresh work on neighbors. The narrow lesson is that a validation-based policy is not a one-time check performed only when a route first appears. Changes in the supporting data can matter too. RFC 9324.
In the fictional archive's migration, the team should preserve the sequence of intended changes and observed effects. An authorization published at one moment may not be reflected everywhere at that same moment. An observer's record needs its collection time and viewpoint. Without those details, two accurate observations can appear contradictory simply because they describe different states of the system.
This is also why retrospective certainty should be resisted. A current Valid result does not prove that the same announcement was Valid throughout an earlier disruption. A present mismatch does not establish when it began. If the necessary historical records were not retained, the honest conclusion may be that part of the sequence cannot be reconstructed.
A good incident report separates what is directly observed, what is inferred and what remains unknown. That discipline is more valuable than forcing every event into a clean narrative in which a single configuration change immediately explains every user's experience.
Broad permission can conceal unnecessary exposure
Authorization design has a tradeoff between convenience and specificity. A broad statement may accommodate anticipated changes, but it can also authorize more than the organization actually needs. The question is not whether every broad authorization is wrong. It is whether its breadth has a documented purpose and whether the resulting exposure is understood.
RFC 9319, an October 2022 best-current-practice document, recommends minimal ROAs where possible and warns about unnecessarily permissive use of the maximum-length field. It discusses exceptions and operational contexts, including mitigation services. Its historical measurements should not be presented as current global prevalence. This article uses the document for its bounded design principle, not as a live count of vulnerable networks or a guide to exploiting them. RFC 9319.
For the fictional archive, a useful analogy is access management. Permission granted for convenience can outlast the event that justified it. The existence of a valid permission does not show that its current breadth was recently reviewed. That is an organizational inference, not a claim that routing authorizations and user accounts have identical technical behavior.
A review process could ask why each exceptional authorization exists, which planned activity requires it and who will revisit it. The answer may justify retaining it. The value of the exercise is not automatic restriction; it is making the decision explicit. A system that supports flexible operations should also support knowing which flexibility is intentional.
Public reporting should avoid a binary contest between “secure” and “insecure” when the underlying evidence concerns a specific configuration choice. The constructive question is whether the authorization matches the intended routing behavior closely enough for the organization's stated risk model.
An origin check is not a route-leak detector for everything
A route can originate from an authorized network and still be propagated in a way that violates the intended relationships among networks. Origin authorization and propagation policy are different dimensions. Confusing them can make a valid result seem stronger than it is, or make a remaining incident look like proof that origin validation has no value.
RFC 9234, published in May 2022, addresses route-leak prevention and detection using BGP roles and an Only-to-Customer attribute. Its mechanism concerns relationships and propagation rules, not merely whether the origin is authorized. The specification is evidence that routing security has multiple complementary control problems. It is not evidence that every network has deployed the mechanism or that it eliminates all possible routing failures. RFC 9234.
Imagine a fictional package-delivery arrangement in which the sender is legitimate but an intermediary sends the package through a channel it was not supposed to use. Checking the sender and checking the permitted forwarding relationship answer different questions. The analogy is deliberately limited; Internet routing has its own mechanisms and cannot be reduced to a postal system. It nevertheless clarifies why one successful check does not settle every other check.
For an institution buying connectivity, this argues against a single checkbox called routing security. The institution can ask the supplier to describe how origin authorization, received-route policy, leak prevention, monitoring and incident response fit together. Some answers may be constrained by the supplier's network relationships. Those constraints should be stated rather than concealed by one umbrella term.
The public-interest standard is not perfection. It is a coherent account of which failure modes a control addresses and which require additional measures. That account makes investment easier to evaluate because the promised benefit has a defined target.
A measurement must name its denominator
A count of authorizations, a count of validated payloads, a share of announced prefixes and a share of users are not interchangeable denominators. A statistic can be accurate and still mislead if a headline silently swaps one unit for another. The same applies when measurements of IPv4 and IPv6 are blended into a single number without an explanation of how they were combined.
NIST's RPKI Monitor methodology is unusually explicit about its boundary. It analyzes public routing and RPKI data, but says it does not measure which operational networks are actually filtering routes based on RPKI. Its statistics are intended for research and standards discussions rather than direct network operations. The methodology also identifies the public collector data on which its observations depend. NIST RPKI Monitor methodology.
An original numerical example makes the denominator issue visible. Suppose a fictional dataset contains one hundred announced prefix-origin pairs, of which eighty have a particular validation state. That is eighty percent of the observed pairs. It says nothing by itself about the fraction of people whose traffic encounters a filtering decision. Some pairs may serve many people, some few, and the observers may not see every relevant route.
A second fictional dataset could contain the same address space represented by a different number of announcements. Its prefix count could change even though the population of users did not. This does not make prefix-based measurement useless. It makes the unit essential to the interpretation.
The reader should be able to reconstruct the question the statistic answers. If the article cannot state the unit, observation period and collection method in ordinary language, it should not use the number as evidence of a broader security outcome.
Filtering is harder to observe from outside
Some network behavior is visible through public routing collectors. Other behavior must be inferred from carefully designed measurements. A route absent from one observer's view may have been filtered, never selected, never exported toward that observer or affected by another policy. An external study needs a method capable of distinguishing the possibilities relevant to its claim.
The TORCH preprint, submitted on March 31, 2026, presents an original approach to studying invalid-route filtering in IPv6. Its authors emphasize limitations in existing observability and distinguish routing information from traffic reachability. This article uses the author abstract to establish the study's question and method at a high level; it does not reproduce its headline percentage as a universal deployment rate or provide its measurement procedure as an operational recipe. TORCH author preprint.
The broader inference is methodological. A measurement of what a network advertises and a measurement of where traffic can travel may disagree without either being fabricated. They observe different layers. Understanding the disagreement requires examining assumptions about visibility, route selection and the relationship between the control plane and the data plane.
For the fictional archive, an outside measurement can be a valuable prompt for investigation. It should not automatically outrank the operator's internal evidence, nor should internal confidence dismiss it. The two parties can ask whether they observed the same addresses, time interval, route and address family. If not, the first task is to align the question before comparing the answers.
This is an important form of accountability. It allows independent researchers to challenge broad deployment claims while requiring their own claims to remain proportional to the method. Transparency works best when both the operator and the observer explain what they can and cannot see.
Why a protected network is not the same as a protected user
A person usually experiences routing as a connection that works, slows down or fails. The underlying path may cross several networks, and the path in one direction need not tell the whole story of the return journey. It is therefore risky to translate a count of participating networks directly into a count of protected people.
Consider a fictional town whose residents use several connectivity providers. The archive's hosting provider may apply a well-defined validation policy, yet residents' traffic can still depend on decisions made elsewhere. Conversely, improvements by a large transit provider may affect users whose local provider has not changed its own deployment statement. The example illustrates interdependence; it does not quantify any actual provider's protection.
A public dashboard could communicate this by separating local commitments from inferred wider effects. Local commitments include actions the reporting organization can verify directly. Wider effects require a stated model or measurement. The distinction prevents an organization from claiming all benefits that happen to coincide with its deployment, while still allowing it to explain why its contribution matters beyond its own customers.
The same reasoning applies to resilience claims. A service may be reachable through an alternative path during a disruption, but that does not mean the primary path was secure. A user may avoid an affected route by circumstance rather than by an intentional control. Success in one observed connection is evidence about that connection, not a complete audit of the system.
The most useful consumer-facing assurance is therefore layered. Explain what the supplier does, what it monitors, how it responds to reports and where its control ends. A limited but verifiable assurance is more valuable than an unqualified promise that no routing incident can affect the customer.
A migration rehearsal should test coordination
The fictional archive's move offers a practical way to evaluate organizational readiness without creating a public incident. Before the change, the archive and its providers can agree on the intended routing arrangement and the records that should support it. The exercise should be performed by authorized operators within their own controlled scope. This article does not supply commands or a universal cutover sequence.
The rehearsal's central question is whether the relevant people share the same model of the change. Who controls the address resources? Who can update the authorizations? Who will originate the routes? Who can observe the result from the relevant locations? Who has authority to halt the migration if the evidence does not match the plan? A gap in these answers can matter as much as a technical defect.
The archive should also identify which activities are reversible and what evidence will trigger a reversal. A rollback that restores one configuration but leaves a related authorization inconsistent may not restore the intended state. The plan should describe the desired relationship among components, not merely a list of buttons to undo.
An especially useful rehearsal outcome is discovering that one team lacks access to a necessary record or contact. That finding can be addressed before the service is moved. Treating the rehearsal as a performance in which everybody must appear prepared would waste its purpose. The objective is to expose dependencies while the consequences are controlled.
Afterward, the institution can preserve a short acceptance record: the agreed configuration, the observations made, unresolved concerns and the person who accepted the residual risk. Such a record supports later investigation without pretending that a rehearsal proves every future change will succeed.
Invalid alerts need triage, not automatic accusations
An alert is a statement about a condition observed by a system. It is not necessarily a statement about motive, impact or cause. The fictional archive may receive an alert about a route it believes is legitimate. A responsible response begins by preserving the observation and identifying the exact claim, rather than immediately announcing an attack or dismissing the alert as noise.
The first distinction is between the observed mismatch and its effect. Did users actually lose reachability? Which observers reported the condition? Was the affected route selected, or was another route used? Did the condition coincide with an authorized change? These questions help establish impact without requiring a premature conclusion about intent.
The second distinction is between a local record and a globally uniform state. Different observers may be using data collected at different times. The archive should seek the relevant timestamps and validation context before treating disagreement as evidence that one party is incompetent. A useful incident record retains the original observations even after the mismatch has been resolved.
The third distinction is between fixing the immediate condition and explaining why it occurred. A quick correction may restore service while leaving the organizational cause untouched. Perhaps an ownership change was not reflected in a maintenance process, or a scheduled operation lacked coordination. The post-incident review should address that cause without inventing blame unsupported by the available record.
A public statement can be concise and still preserve these distinctions. It can say what was observed, which service effects were confirmed, what was changed and what remains under investigation. That is more informative than attaching the word hijack to every unusual routing event, and more accountable than describing all disruptions as unspecified technical difficulties.
Procurement should ask for evidence, not a logo
A purchasing questionnaire often rewards short answers. “RPKI supported” fits neatly into a cell. Unfortunately, support can mean that a product has a feature, that one part of a network uses it or that a complete operational process maintains and checks it. These meanings differ enough that the questionnaire should not treat them as equivalent.
The fictional archive can ask for a statement of implemented scope and responsibility. The supplier need not reveal sensitive internal details to explain whether its claim concerns published authorizations, received-route validation, policy enforcement or monitoring. It can state relevant exceptions and identify how the commitment is reviewed. A dated answer is more useful than an undated marketing paragraph.
Evidence can take several forms. A configuration review, a controlled acceptance test, an operational monitoring record and an independently observed behavior each have strengths and limits. The institution should not demand one form merely because it looks most technical. It should ask which evidence supports the specific promise being purchased.
Contract language should also anticipate change. A service can move between infrastructure arrangements, and an organization can acquire another network with different practices. If the assurance applies only to a named scope, the customer should know when that scope changes. Otherwise, a truthful statement at procurement can become a misleading assumption later without anybody deliberately falsifying it.
This is not legal advice or a universal contract template. It is a recommendation for clearer technical claims. A supplier that can explain its boundaries should not be penalized in favor of one offering a broader but untestable promise. Good procurement makes honesty operationally useful rather than treating caveats as a sign of weakness.
Independent checks should remain authorized and proportionate
Routing research can affect shared infrastructure if poorly designed. A public-interest desire to test a claim is not permission to announce somebody else's address space, alter another network's configuration or generate disruptive traffic. The distinction between observing a public dataset and actively changing the conditions being measured is fundamental.
For the fictional archive, the safest starting point is often its own records and authorized supplier evidence. Public monitoring can add context. A more active test would require explicit scope, competent operators, agreed boundaries and a plan for unexpected effects. The institution should not outsource those judgments to a generic checklist copied from an article.
A useful measurement proposal states what question it will answer and what it cannot answer. It identifies the systems under the tester's control and the evidence needed to stop if the result becomes ambiguous or risky. The proposal should not assume that broader reach automatically produces better knowledge. A narrow, well-understood test can be more informative than a sweeping experiment whose side effects and observation biases are poorly characterized.
The same discipline applies when publishing results. Aggregate findings should not expose unnecessary operational details about unrelated parties. Claims of vulnerability should distinguish directly observed behavior from inferred possibilities. If a finding depends on a particular time and viewpoint, those qualifiers belong with the claim rather than in a remote appendix.
Accountability and restraint are compatible. Independent scrutiny is valuable precisely because it can challenge reassuring narratives. Its credibility grows when the scrutiny respects authorization, documents uncertainty and avoids creating the kind of disruption it is intended to help prevent.
Make the dashboard answer several small questions
A single green indicator is attractive because it simplifies a complex system. It can also conceal which part of the system is healthy. The fictional archive would be better served by a small set of clearly defined indicators than by a composite score whose interpretation nobody can explain.
One indicator could describe whether intended authorizations match the organization's own current routing plan. Another could describe whether the validation-data service is operating within its defined freshness expectations. A third could report the scope of received-route policy. A fourth could summarize unresolved discrepancies and their confirmed service impact. These are proposed categories, not measured values or a claim that all can be reduced to one universal percentage.
The dashboard should retain unknown as a legitimate state. Missing evidence is not the same as a passing result. Equally, a temporary loss of a monitoring signal is not automatically proof that routing has failed. Labels should explain the difference between an observed problem and a gap in observation.
Historical comparisons need stable definitions. If the organization expands its monitored scope, an apparent increase in alerts may reflect improved visibility rather than worsening behavior. If it changes the unit of measurement, the old and new totals may not be directly comparable. The dashboard should annotate those changes instead of drawing an uninterrupted trend line that implies continuity where none exists.
A useful visual can show the relationships among publication, validation, policy and observation without pretending to know their numerical contribution to safety. Conceptual diagrams are appropriate when the evidence supports a structure rather than a quantity. Inventing a percentage for each layer would make the design more colorful and the explanation less truthful.
Keep emergency exceptions from becoming the permanent system
An organization may need an exception while investigating a disruption. The important governance question is whether the exception remains visible after the immediate pressure has passed. A temporary departure from the intended policy can become difficult to distinguish from normal practice if nobody owns its review. This is a general operational risk, not an allegation about a named network.
For the fictional archive, an exception record would state the problem being addressed, the responsible decision-maker and the conditions for reassessment. It would preserve the difference between a narrowly scoped intervention and disabling an entire control. The record would also identify what evidence is missing, so the team does not later interpret the absence of further complaints as proof that the underlying issue was resolved.
An exception can be justified without becoming invisible. Its continued presence should prompt a deliberate decision rather than depend on whether the person who created it remembers to revisit it. If the intended policy cannot be restored, the organization should update its assurance statement to match reality. A technically convenient workaround should not leave customers relying on a commitment that no longer describes the service.
This practice helps separate availability management from security theater. The goal is not to forbid operational judgment during a difficult event. It is to make that judgment accountable and recoverable, so an emergency response does not quietly redefine the system's long-term protection.
What a credible progress claim looks like
A credible progress claim has a subject, an action, a scope, a date and supporting evidence. It might describe more resources with published authorizations, a broader set of routers using a defined policy or improved handling of a documented operational dependency. It should not collapse those achievements into a claim that routing attacks have become impossible.
A progress report should also make maintenance visible. An authorization that accurately represents an organization's intentions today can become stale after a change. A policy that works in a test can drift during later operations. The achievement is not simply installing a feature; it is sustaining the relationship between intended behavior, published information and observed decisions.
For the fictional archive, success would mean being able to explain that relationship before, during and after its migration. The institution would know which parties own the relevant decisions, what evidence supports their commitments and how discrepancies are handled. It would still depend on other networks, but it would not confuse that dependence with helplessness.
RPKI's value is strongest when its promise remains exact. It provides a way to make particular routing authorizations verifiable and to use that information in network decisions. Turning that capability into dependable protection requires accurate publication, deliberate policy, reliable operations and honest measurement. A signed route is a meaningful step. The protected journey is the larger claim, and it deserves the larger body of evidence.
Evidence and publication notes
Prepared November 1, 2026. Historical standards and data retain their dates; no live worldwide adoption percentage is asserted. The APNIC report is an author measurement account using RPKIViews snapshots; the chart must retain its year-end object-count denominator. TORCH is a March 2026 author preprint described from its abstract, without adopting its headline percentage as a universal estimate. NIST SP 1800-14 is described from its official abstract; no current vendor recommendation is inferred. RFCs were opened directly, with the 6811/8481/9324 clarification chain and 9582 replacement of 6482 identified. The archive and procurement scenarios are fictional editorial analysis. No unauthorized testing, attack procedure, actual incident allegation or live configuration change is included.