Summary

  • RFC 8808 permits a device to offer a factory-reset operation without offering the datastore through which a controller could inspect its factory configuration.
  • Resetting the configuration can remove management reachability. Factory-installed identity material can remain even as locally generated records and credentials are removed.
  • The specification explicitly says that owners must not rely on this reset for forensic unrecoverability or compliance with a data-cleansing standard. Recovery and disposal need evidence beyond the operation's name.

The destination matters more than the button

Consider a remote device whose current configuration supplies the address and management settings through which its operator reaches it. The operator decides to abandon that configuration. A factory reset replaces it with the preset state, and the old management path disappears. There need be no defective reset in this sequence. The connection may have depended on the very configuration that the authorized action removed.

This is a standards-derived illustration, not a report of a particular outage. Its importance lies in the direction of the uncertainty. A team may know exactly which device it intends to reset while knowing much less about how that device will become reachable afterwards. Identifying the target and understanding the destination are separate tasks.

RFC 8808 makes this unusually explicit. It warns that immediately resetting the read-write datastores may make the device unreachable as a network host. It tells operators to understand a vendor's post-reset behavior. The operation can therefore be well defined at the configuration boundary without being a complete remote-recovery service.

There is a second asymmetry. The means of inspecting that destination is optional. A device may implement the reset RPC without implementing the factory-default datastore. The standard describes the consequence as losing the ability to determine the default configuration programmatically. An inventory entry saying “factory reset supported” cannot settle whether the controller can see what it is about to install.

The commercial question is consequently more precise than whether a box can be reset. Does the buyer possess current, device-applicable knowledge of the destination, and a route to regain control after the old one has gone? The RFC provides the reason to ask. It does not answer for an unexamined product.

Reset does not mean one empty state

The operation resets all supported conventional read-write configuration datastores to factory-default contents. The running configuration is in scope; startup and candidate configurations are in scope when supported. This is not an instruction to create every datastore on every implementation. Nor is it a promise to leave their contents empty. A vendor's preset configuration is still configuration.

Read-only datastores obtain their contents from other datastores. All data in dynamic configuration datastores must be discarded. The operational datastore must reflect the device's actual operational state after the defaults have been applied. These rules distinguish the configuration supplied to the device from the state that results.

That last distinction prevents an important shortcut in reporting. A saved copy of the expected defaults can describe what should be installed. It cannot, by itself, establish that the device acquired an address, exposed the intended management service or reached an external dependency. Those are consequences to observe, not values to assume from a successful comparison of configuration documents.

The optional factory-default datastore contains configuration nodes, with a schema that must match or be a subset of the conventional configuration schema. The vendor defines its contents, and those contents must persist across device restarts. If the datastore is supported, it must appear in the YANG library's datastore list.

Persistence is narrower than permanent immutability. The server sets the contents in an implementation-dependent way. Ordinary management operations cannot change them unless specialized, dedicated operations are provided. None of that establishes that defaults remain identical across different products, software releases or such dedicated mechanisms.

This places a quiet versioning problem inside a familiar maintenance action. A default configuration captured for one applicable state cannot be assumed to describe another merely because both devices carry the same reset label. The article's inference is about evidence management, not a finding that vendors commonly change defaults without notice.

A document can illuminate the destination, but not guarantee arrival

The absence of a readable factory datastore does not logically mean that no documentation can exist. RFC 9195 defines a format for YANG instance data that can be delivered offline, including through ordinary product-documentation channels. Its factory-default use case explicitly points to RFC 8808.

That gives a buyer and supplier a possible artifact around which to organize the discussion. Instead of exchanging an assurance that settings will be “standard,” they can identify a particular data set, its relevant schema and the circumstances in which it remains representative. RFC 9195's content-schema concept encompasses modules, revisions, supported features and deviations.

The format's lifecycle warning is as important as its structure. A data set is created at a point in time. If the underlying data changes and the set is not updated, it no longer represents the current data. A neatly preserved file may therefore be excellent evidence of an earlier expectation and poor evidence of today's reset destination.

The document also permits partial data sets, including specified exceptions to constraints that would otherwise apply. It can carry configuration and operational state together. Parsing such a file successfully is not a certificate that it is complete, deployable or a faithful description of a particular live device.

These are reasons to qualify the artifact, not reasons to reject it. A partial description may answer an important question about management defaults while leaving other behavior unresolved. Its value increases when the missing scope is explicit. Calling it a full recovery plan would make it less informative by attributing assurances that its format never supplied.

Nor does RFC 9195 require every vendor to ship this documentation. Its schema and descriptive metadata guidance also contains recommendations, not a universal mandate to embed every relevant detail in every file. Procurement terms could request stronger evidence, but those terms would be additional commitments, not obligations discovered in the standard.

The right to reset is not a surviving connection

The factory-reset RPC carries the NACM default-deny-all annotation. That is a deliberate signal that invoking it is sensitive. Reading the phrase as an absolute impossibility for ordinary operators, however, would misunderstand the access-control model.

Under RFC 8341, with NACM enabled, an explicit matching access rule can authorize the operation for a user who is not in a recovery session. Default denial applies when the normal rule processing has not supplied permission. Disabling NACM or using a designated recovery session changes that enforcement path.

The recovery-session concept itself is optional. Its configuration and identification are implementation-specific and outside RFC 8341's scope. The presence of the concept in a standard does not show that a purchased device has a usable recovery mechanism, that staff have access to it, or that it remains reachable after factory reset.

This is where three forms of control are easily confused. An access policy can authorize the destructive transition. A datastore or document can reveal its configuration destination. A separate operational arrangement can make that destination manageable. Strength in one does not automatically compensate for absence in the others.

A secure management transport does not collapse these distinctions. Protecting the channel says nothing, on its own, about which user may invoke reset. Granting permission says nothing about whether the channel will survive replacement of its supporting configuration. A recovery role says nothing about the physical or network path needed to use it.

What leaves the device, and what stays

RFC 8808 also requires restoration of nonvolatile storage to factory condition. Depending on the system, this can entail deleting dynamically generated files, including locally generated keys, certificates, logs and temporary material. Factory-installed cryptographic material is retained; the RFC gives an Initial Device Identifier as an example.

The practical asymmetry is substantial. The device can retain evidence of its factory identity while losing records and configuration accumulated during its operational life. “The device is still identifiable” does not mean that the old management credentials, service settings or local incident history remain available.

The reverse inference fails too. Removing a local credential from ordinary use does not establish that its bytes are unrecoverable. RFC 8808 recommends thorough deletion of security-sensitive data, yet explicitly warns owners not to rely on the reset for resistance to forensic recovery or compliance with any data-cleansing standard.

That warning is not an allegation that every implementation leaves recoverable secrets. It is a limit on what the standardized operation can be used to prove. A disposal decision requiring a particular erasure assurance needs evidence appropriate to that assurance. The reset's name cannot supply it.

Recovery work and equipment disposal thus share a command without sharing an acceptance criterion. An operator restoring service cares about access, configuration and usable operation. An owner retiring equipment may care about retained sensitive material. A reset may be relevant to both workflows while completing neither on its own.

An old specification, a recent editorial correction

The RFC 8808 errata record contains Verified Editorial erratum 9033, reported and verified on 23 July 2026. It adds the missing indication that the document updates RFC 8342. That improves the documentary relationship; it does not introduce a new reset operation or strengthen the data-erasure guarantee.

The distinction matters when reading standards news. A recent correction date does not make the underlying capability new. The reporter's observation about implementation awareness should likewise not be promoted into an independently measured census of deployed devices.

The companion checks have different statuses. RFC 8341's errata include Reported Technical 8302 concerning RESTCONF event-stream mapping and Rejected Technical 6493 concerning identifier prefixes. Neither supplies an accepted change to this reset argument. The RFC 9195 query returned no matching errata at the research snapshot; that is not a promise that the document has no possible error.

Responsibility follows the consequence

Lu Heng's essay on agency in Internet governance supplies a useful analytical question: does control sit with those who bear its consequences? Applied here, the question concerns the party defining defaults, the party granting reset authority and the party responsible for recovering the device. It is not evidence that Lu Heng examined this protocol or that any vendor acted improperly.

His essay on BTW's purpose also argues for describing structures rather than campaigning for actors. The relevant structure here is a transition that can remove the means of observing and managing its own aftermath.

These sources do not establish reset duration, current adoption, product behavior, attack frequency or a measured recovery rate. No device was reset or probed for this report. What they establish is enough to reject a misleading equivalence: returning to preset configuration is not the same event as recovering control, and neither is proof that the device has forgotten its operational past.