R2v3 Certification: What It Covers, and Why Appendix B Decides Your Scope

R2v3 certification is awarded to facilities, not to software, equipment, or individual devices [1]. If a vendor tells you their product is R2v3 certified, they have described something the standard does not issue. Your facility carries the certification. Your tooling produces the evidence that certification depends on.

The part most teams underestimate is scope. R2v3 is not one bar you clear. It is ten Core Requirements that apply to everyone, plus a set of appendices that attach based on what your facility actually does. Get the appendix scoping wrong and you either fail an audit or pay for a scope you never needed.

What R2v3 is

R2v3 is the third version of the R2 standard, published by SERI, Sustainable Electronics Recycling International [1]. It governs responsible handling of used electronics across environmental, health, safety, and data-security dimensions, and certification is granted at facility level [1].

The structure has two layers.

Ten Core Requirements apply to every certified facility: Scope, Hierarchy of Responsible Management Strategies, EH&S Management System, Legal and Other Requirements, Tracking Throughput, Sorting, Categorization and Processing, Data Security, Focus Materials, Facility Requirements, and Transport [1].

Six Appendices attach conditionally: A Downstream Recycling Chain, B Data Sanitization, C Test and Repair, D Specialty Electronics Reuse, E Materials Recovery, and F Brokering [1].

For anyone erasing devices for resale, one of those appendices is not optional.

Core 7 versus Appendix B, the distinction that decides your scope

This is where scoping goes wrong most often, so it is worth being precise.

Core Requirement 7, Data Security, applies to all R2 facilities. SERI's own framing is that all R2 facilities are responsible for properly securing data devices, planning for their sanitization, and directing them accordingly [2]. Core 7 requires a data sanitization plan with appropriate security controls, but it does not mandate specific destruction methods [2].

Appendix B, Data Sanitization, applies to a narrower set. It covers facilities with the specific skills and competency to provide the enhanced level of services and security controls it specifies [1]. And it carries a hard rule: any R2v3 facility that performs logical sanitization must be certified to Appendix B [2].

Read that again if you run erasure. Logical sanitization is the software-based erasure that leaves a device intact and resaleable, as opposed to shredding it. If your facility does that, Appendix B is not a nice-to-have you grow into. It is mandatory scope.

Appendix B goes beyond Core 7 by specifying methods, requiring adherence to customer requests, and mandating video recording of physical destruction processes [2]. It also requires stronger sanitization processes and security controls, specific device tracking and records, and demonstrated expertise for logical data sanitization to enable device reuse [1].

The pattern is consistent: Core 7 asks whether you have a plan. Appendix B asks you to prove, device by device, that you executed it.

Why the evidence burden lands on per-device records

An auditor assessing Appendix B is not satisfied by a policy document. The requirement set points at device tracking and records, which means the unit of proof is the device, not the batch [1].

That aligns with where the sanitization standards landed independently. NIST SP 800-88 Rev. 2 recommends completing a certificate of sanitization for each device, recording the method, the technique, the tool and its version, the verification performed, and a signature [3].

Two different bodies, two different purposes, same practical conclusion: per-device evidence or it did not happen.

If you want the underlying method framework, we cover it in what data sanitization requires, and the specific fields an erasure certificate needs in certificate of data destruction.

Want to see what per-device evidence looks like across a mixed fleet? Request a demo.

Scoping your appendices honestly

A short way to think about it, before you talk to a certifying body:

If you receive data-containing devices at all, Core 7 applies. If you run software erasure to return devices to service or resale, Appendix B applies and is mandatory. If you test and repair, Appendix C enters scope. If you broker without physically handling, Appendix F does. If you recover materials, Appendix E [1].

Facilities commonly get this wrong in one direction: they certify to Core requirements, run logical erasure anyway, and discover the gap during audit rather than before it. The determination is not a judgement call, it follows from what you physically do.

Where R2v3 sits alongside the other frameworks

R2v3 is a certification programme for facilities. NIST SP 800-88 is a guidance document for sanitization outcomes. IEEE 2883 is a technical standard for sanitization techniques. HIPAA and GDPR are legal obligations on data controllers. They are not competing options and none substitutes for another.

In practice they stack. R2v3 Appendix B tells you your facility must demonstrate competent logical sanitization with records. NIST 800-88 Rev. 2 tells you what assurance level the sanitization should reach and what the certificate should record [3]. The regulation tells you which data made the whole exercise mandatory in the first place.

The wider workflow those obligations sit inside is covered in what IT asset disposition involves.

Producing the evidence without slowing the line

The operational problem is rarely understanding the requirement. It is generating defensible per-device records at throughput, in a form that survives an auditor reading it a year later.

Phonecheck erasure produces a signed certificate of erasure and a Device History Report for every device processed, and those reports are recognised by major resale marketplaces [4]. The audit artefact and the resale artefact are the same record, created once when the device is handled rather than reconstructed later.

The standards page lists what the platform aligns to, the Device History Report shows how per-device evidence is presented, and workflow automation handles routing when device types follow different paths.

Request a demo to walk through the evidence trail on your own device mix.

Frequently asked questions

Can software be R2v3 certified?

No. R2v3 certification is granted to facilities [1]. Software and equipment can support a facility's compliance by producing required records, but they do not themselves hold the certification.

Do we need Appendix B, or is Core 7 enough?

If your facility performs logical sanitization, Appendix B is mandatory. SERI states that any R2v3 facility performing logical sanitization must be certified to Appendix B [2]. Core 7 applies to all facilities regardless [2].

What is the difference between logical and physical sanitization here?

Logical sanitization is software-based erasure that leaves the device usable. Physical destruction renders it unusable. Core 7 permits either physical destruction under its own requirements or enhanced sanitization methods under Appendix B [1].

How many Core Requirements and appendices are there?

Ten Core Requirements and six appendices, A through F [1].

Does R2v3 tell us which erasure method to use?

Core 7 requires a data sanitization plan but does not mandate specific destruction methods [2]. Appendix B specifies methods and requires adherence to customer requests [2]. For the technical assurance framework, NIST SP 800-88 Rev. 2 is the reference, and it directs technique questions to standards such as IEEE 2883 [3].

Sources

1. Summary of R2v3 Requirements, SERI (Sustainable Electronics Recycling International), 2021.
2. Difference Between "Core 7-Data Security" vs. "Appendix B-Data Sanitization" Requirements, SERI Knowledge Base.
3. NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, NIST, September 2025.
4. Phonecheck internal product marketing context, source of truth for product claims (updated 2026-07-02).