Which regulation governs FCC permissive changes?

47 CFR 2.1043 sets the framework. It distinguishes three classes (Class I, Class II, Class III) according to the nature of the change applied to an equipment already holding an authorization. Class I filings stay internal to the manufacturer. Class II and Class III go through a TCB (Telecommunication Certification Body) with grant update. The FCC additionally publishes KDB 178919, which details criteria and provides sector examples. A change that alters the nature of the equipment (modulation, band, full RF architecture) falls outside permissive-change scope: it requires a new application with a new FCC ID, a regime sometimes informally called Class IV.

Does a firmware update force a Class II or Class III filing?

Class III is reserved for equipment declared SDR (Software Defined Radio) at initial filing. A standard Part 15 product with non-SDR firmware does not fall under Class III. A firmware update that modifies measured RF parameters (power, spectral mask, listen-before-talk timing, channel table) requires a Class II filing. A purely application-layer update (user interface, higher-layer protocol logic, software security patch leaving the radio layer untouched) stays Class I with no filing. The boundary is drawn on measured impact against the parameters listed in the initial test report.

How does RED handle a substantial modification?

Directive 2014/53/EU does not contain a regime equivalent to FCC permissive change. Article 10(9) requires the manufacturer to maintain conformity throughout the product lifecycle. The 2022 Blue Guide develops the general notion of substantial modification: a change that affects essential requirements 3.1 (safety, EMC), 3.2 (efficient use of spectrum) or 3.3 (cybersecurity, privacy, fraud) requires a fresh conformity assessment, an updated Annex V technical file and a new dated DoC. The manufacturer qualifies substantiality under its own responsibility, with traceable analysis defensible under market surveillance.

What is the status of a mandatory security update under RED 3.3 and CRA?

RED Article 3.3(d, e, f) and the Cyber Resilience Act regulation require an active security maintenance posture. Issuing a security patch is expected and does not by itself constitute a substantial modification. However, if the patch alters a function covered by essential requirements (for instance a change in radio-link encryption algorithm, a revised identifier-handling logic, a modified pairing behaviour), a conformity impact analysis remains required. The practical rule: a security patch that does not affect parameters measured under EN 18031-1/2/3 and that does not introduce a new network function falls under routine maintenance. Beyond that, return to 3.3 assessment.

How does MDR handle a software change to a medical device?

Regulation 2017/745 Article 120 and MDCG guidances distinguish significant modifications (notified-body certificate amendment or full re-evaluation) from non-significant ones (technical update with tacit notification). For medical device software (MDSW), the classification follows IEC 62304: a Class A change stays internal with regression testing, Class B requires a reinforced risk review, Class C requires full verification and often a notified-body review. The substantive criterion remains the effect on safety and intended performance. A critical security bug fix is generally treated as non-significant if it does not alter the intended function, but must still be notified.

Does a component substitution touching the RF chain always require a Class II filing?

Almost always. An active component in the RF chain (oscillator, power amplifier, mixer, LNA) or a structuring passive (balun, output LC filter, antenna) modifies measured RF characteristics. Targeted retesting of affected parameters (fundamental power, spectral mask, out-of-band and spurious emissions, EN 301 489 EMC compliance) precedes the Class II filing under the same FCC ID. An internal supply-rail decoupling passive with no contact with the RF chain may stay Class I with an internal note. The decision is taken by explicit analysis, never by default.

What PTCRB obligations apply when a cellular module is modified?

The PTCRB program requires notification of any hardware or firmware modification affecting certified cellular RF performance. Three regimes coexist: Delta Certification for a limited modification (typically modem firmware or a minor PCB variant), Continuation for a new variant remaining under a parent certificate, Full Certification for a major change (new chipset, added bands). Cellular operators (AT&T, Verizon, T-Mobile, Orange, Telstra) generally align their own processes on the PTCRB verdict and add their network tests. An unnotified modem firmware modification invalidates PTCRB status and exposes the integrator to operator eligibility removal.

Which documents should be archived for a permissive-change submission?

A standard change file contains the signed regulatory impact analysis, the targeted or full retest report from an accredited lab, the modification cover letter sent to the TCB (for Class II and Class III), the updated FCC grant published by the FCC, the incremented RED DoC version when applicable, the versioned as-built BOM and the CCB (Change Control Board) procedure that approved the decision. Archive duration is ten years for RED and other New Approach directives, and at least five years for the FCC after last manufacture date.

Change management: FCC Class II permissive and RED delta

Author Hugues Orgitello Last updated 27 May 2026 ~12 min read

Guide - Certified product change management

A certified product is never frozen. Component shortages, firmware updates introducing a new radio feature, hardware refreshes to reduce BOM cost, antenna or shielding redesigns affecting SAR, regulatory evolution forcing a security patch: every modification reopens the question of conformity reconduction. The FCC, ISED Canada, RED and MDR frameworks do not handle change identically, yet they converge on a single operational principle: separate what can be absorbed through documentary update from what requires retesting and a new declaration. This guide explains the FCC permissive-change regime under 47 CFR 2.1043, the notion of substantial modification under RED Article 10(9), the MDR Article 120 classification of changes, and proposes a CCB (Change Control Board) workflow operable across a product portfolio.

Context: why change management shapes the entire lifecycle

Most hardware companies do not treat conformity as a one-time event at initial certification, but as a continuous state maintained throughout the commercialisation period. Five classes of modification stress this continuity:

Shortages and component substitutions. The 2020 to 2023 cycle put this topic on every electronics design office agenda. A component substitution can stay transparent or trigger a retest depending on category and role. The guide on component substitution rules details the matrix per directive.
Firmware updates with radio impact. Adding a band, changing a listen-before-talk algorithm, a new per-channel power table, a logical antenna change or digital impedance adaptation are modifications where the Class I / Class II / Class III boundary plays out.
Hardware refresh. BOM cost reduction, microcontroller end-of-life migration, transition from a radio module to its same-manufacturer successor: each case may be handled differently depending on electrical footprint and scope.
Redesign affecting SAR or overall EMC. A mechanical refresh modifying the integrated antenna or the distance to the human body reopens SAR testing under Part 2 Subpart J and often requires a new application. A chassis refresh affecting shielding reopens EMC testing.
Mandatory security patches. Under RED Article 3.3 and the Cyber Resilience Act regulation, security maintenance becomes an obligation. The boundary between patch and substantial modification is documented by the manufacturer.

The cost of misclassification is asymmetric. Under-classing a change (declaring Class I a Class II change) exposes the manufacturer to an FCC enforcement enquiry, possibly grant revocation. Over-classing leads to avoidable retesting and market delays. Documented analysis discipline is the arbiter.

Three structural shifts have raised the operational stakes of change management. First, regulatory cybersecurity (RED 3.3, CRA, FDA cyber pre-market guidance) brings firmware updates inside the conformity perimeter, whereas they used to sit outside. Second, distributed manufacturing across multiple contract manufacturers means BOM divergences appear silently if PCN tracking is not unified at ERP level. Third, longer support commitments (CRA imposes a five-year minimum support duration for connected products by default) extend the period during which the product can receive substantial modifications. The combined effect is that change-management discipline is now expected to be auditable on demand by national authorities, notified bodies and accreditation auditors, with reproducible traceability from BOM line to grant identifier.

FCC 47 CFR 2.1043: the permissive-change regime

The federal rule 47 CFR 2.1043 organises modifications made to an equipment already holding an FCC Equipment Authorization (Certification, Suppliers Declaration of Conformity, Verification). For certified equipment, the regime distinguishes the following classes.

Class	Regulatory definition	Required action	Effect on FCC ID
Class I	Modification with no effect on measured RF parameters and no effect on compliance with applicable rules	Internal analysis note, archive; no filing	Unchanged
Class II	Modification affecting measured RF characteristics or compliance, but remaining within the same rule sections as the initial authorization	Targeted retest, filing to the initial TCB, FCC grant updated	Unchanged
Class III	Software change to equipment declared SDR (Software Defined Radio) affecting RF characteristics	Class III filing to TCB, targeted retest, grant update	Unchanged
New application	Substantial modification: change of modulation, added band beyond the initial scope, RF architecture overhaul, emitter class change	New full application, new FCC ID	New

The "new application" category is sometimes referenced as Class IV in industry documentation, but the regulation does not formalise this term. The FCC publishes KDB 178919, which details criteria and provides sector examples. For the FCC framework generally, see the FCC pillar.

Class I classification criterion: the modification must be proven to have no effect on measured parameters. The strongest proof is a before/after comparison on an internal instrumented bench or accredited laboratory. A datasheet equivalence alone is not sufficient for an active RF category.

Class II classification criterion: the modification affects measured parameters but conformity to the initial rule sections (Part 15.247 for example) is preserved. The retest is targeted at affected parameters (delta tests), with an analysis memo signed by the responsible RF engineer.

Class III classification criterion: reserved for equipment declared SDR at origin. A classical non-SDR equipment cannot be the subject of a Class III filing, even if its modification is purely software. In that case, a software change affecting RF parameters is handled as Class II or as a new application depending on amplitude.

New application criterion: modulation change, band addition beyond initial scope, change of rule family (Part 15 to Part 22 for example), RF architecture overhaul, or substantial SAR modification. A new FCC ID is issued and the old grant remains applicable to units already produced.

ISED Canada: permissive-change equivalence under RSS-Gen

Innovation, Science and Economic Development Canada (ISED, formerly Industry Canada) applies a parallel regime to the FCC, defined in the RSS-Gen annex and in procedure DC-01. The correspondences are:

ISED Class I, II and III map to the corresponding FCC classes, with filing to a CB (Certification Body) recognised by ISED.
The IC (Industry Canada) number stays unchanged for Class I, II and III.
A substantial modification requires a new application with a new IC number.

Standard practice in combined FCC + ISED certification is to file the modification simultaneously through the same TCB/CB, with a shared dossier. Retest reports are pooled wherever applicable rules allow. Operational divergences mostly concern SAR (occasionally distinct measurements) and administrative declaration regimes (distinct forms).

RED 2014/53/EU: substantial modification, Article 10(9) and Blue Guide

The RED directive does not formalise a class scale equivalent to the FCC's. The general obligation rests on Article 10(9): the manufacturer maintains conformity throughout the equipment lifecycle. The 2022 Blue Guide (Communication 2022/C 247/01) develops the substantial-modification notion: any change that may affect applicable essential requirements reopens the conformity assessment.

For RED, the three essential requirements are:

Article 3.1(a): protection of human and domestic animal health and safety, LVD conformity.
Article 3.1(b): electromagnetic compatibility per the EMC directive.
Article 3.2: efficient use of spectrum.
Article 3.3: additional requirements (interoperability, emergency-service access, cybersecurity via 3.3(d, e, f)).

Any modification touching one or more of these requirements triggers:

Update of the Annex V technical file with retest reports for affected tests.
Reissuance of the Declaration of Conformity (DoC), dated, with an incremented unique identifier.
Notification to the notified body if the initial assessment proceeded via module B + C (EU type examination) or H (full quality assurance) and the modification touches elements covered by the type-examination certificate.

A firmware update adding support for a band that was not in the initial scope mandatorily triggers a 3.2 re-evaluation, with harmonised radio tests on the new band (EN 300 328, EN 301 893, EN 300 220 depending on the case). An antenna or passive RF chain modification typically touches 3.1(b) and 3.2. A cybersecurity-layer overhaul touches 3.3(d, e, f) and requires testing under EN 18031-1/2/3.

Traceability is documented in the Annex V file, kept for ten years after the last placing on the market. For the RED framework generally, see RED pillar.

MDR 2017/745: significant changes, Article 120

The MDR regulation Article 120 and the MDCG 2020-3 Rev. 1 guidance organise modification management through the significant change angle. A modification is significant if it affects:

The design or intended use of the device.
Performance or safety.
The device classification (class up-grading).
The clinical evaluation.

A significant modification triggers an amendment to the CE certificate by the notified body, possibly a full re-evaluation depending on amplitude. A non-significant modification is notified tacitly to the notified body, with Annex II and III technical-file update.

For medical device software (MDSW), IEC 62304 introduces a safety classification by risk level:

IEC 62304 class	Associated risk	Post-modification verification depth
Class A	No injury possible	Regression testing, archive
Class B	Non-serious injury possible	Full regression testing, risk review
Class C	Serious injury or death possible	Full verification, notified-body review often required

A critical security bug fix, even in Class C, is not necessarily significant under MDR if it does not alter the intended function. It remains notified. A new software feature (a new detection algorithm, an alarm threshold change) is almost always significant in Class B or C. For classification, see MDR classes.

Comparison table: FCC, ISED, RED, MDR

Aspect	FCC 47 CFR 2.1043	ISED RSS-Gen	RED Article 10(9)	MDR Article 120
Conceptual framework	Formalised class scale	Parallel scale to FCC	General substantial-modification notion	Significant-change notion
Minor modification	Class I, no filing	Class I, no filing	Technical file update, no new DoC	Tacit notification, file updated
Modification with measured RF impact	Class II, targeted retest, TCB filing	Class II, CB filing	3.1(b)/3.2 re-evaluation, new DoC	Notification
SDR software modification	Class III	Class III	Re-evaluation per impact	Per IEC 62304 classification
Substantial modification	New application, new FCC ID	New application, new IC	New conformity assessment, new DoC	Certificate amendment or full re-evaluation
Product identifier	FCC ID unchanged in Class I/II/III	IC unchanged in Class I/II/III	DoC re-identified at each update	UDI generally unchanged
Body involved	TCB	CB	Notified body where relevant	Notified body
Archive duration	5 years after last manufacture	5 years after last manufacture	10 years after last placing on market	10 years (15 for implantables)

PTCRB and operator acceptance: the cellular layer

For products integrating a PTCRB-certified cellular module, any hardware or firmware modification affecting the cellular RF chain requires notification to the PTCRB program. Three regimes apply:

Delta Certification: limited modification, targeted retest on affected bands.
Continuation: new variant remaining under a parent certificate.
Full Certification: major chipset or band change, full retest.

An unnotified modem firmware modification invalidates PTCRB status and exposes the integrator to operator eligibility removal (AT&T, Verizon, T-Mobile, Orange, Telstra, KDDI). See the PTCRB pillar and 3GPP RF conformance test plan.

RED 3.3 cybersecurity and CRA: maintenance and modification

RED Article 3.3(d, e, f), applicable from 1 August 2025 via delegated regulation (EU) 2022/30, and the Cyber Resilience Act (CRA) entered into force in 2024 with a phased application, require a continuous security-maintenance posture. Delivery of security updates is expected throughout the declared support duration.

The boundary to maintain is the following:

Routine update fixing a vulnerability without altering functions covered by EN 18031-1/2/3 testing (identifier handling, access control, personal-data integrity, network functions): handled as maintenance, journalled but not considered a substantial modification.
Functional update introducing a new authentication method, altering the radio-link encryption algorithm, changing pairing or authorisation behaviour: triggers a 3.3 re-evaluation with targeted EN 18031 tests and DoC update.

The CRA adds a 24-hour vulnerability-disclosure obligation to ENISA for actively exploited vulnerabilities. This obligation is independent from the product-modification regime; it adds to it. For the CRA framework, see Cyber Resilience Act.

CCB workflow: operational Change Control Board

A robust CCB workflow sequences decision-making in six documented steps.

Initiation. A modification request (Engineering Change Request, ECR) is opened. Possible sources: supplier PCN, commercial request, bug fix, feature addition, cost optimisation.
Technical impact analysis. The product engineer qualifies the modification nature: hardware, firmware, mechanical, label. Affected BOM lines are listed.
Regulatory impact analysis. The regulatory engineer rules on the effect against each applicable authority (FCC, ISED, RED, MDR, others). The classification (Class I/II/III/new application; substantial/non-substantial; significant/non-significant) is proposed with written justification.
CCB decision. Committee bringing together engineering, quality, regulatory, manufacturing, commercial. The retest decision is taken: none, targeted, full. The retest scope is defined precisely.
Execution. Retest in an accredited laboratory, report drafting, TCB or CB filings, technical file update, DoC reissuance.
Closure and traceability. The ECR is closed with link to produced artefacts (report, TCB cover letter, published FCC grant, dated DoC, as-built BOM). The modification enters production at a defined cutover.

The regression test matrix is a key step-5 deliverable. It lists initial tests and assesses, parameter by parameter, the need to retest. A parameter whose delta between initial and modified architecture is documented as zero by analysis may be exempt from retest under traceability. A parameter whose effect is estimated non-zero is retested.

Typical contents of a modification dossier

Beyond the regression test matrix, a mature modification dossier contains several systematic deliverables. Cross-traceability between these artefacts conditions the strength of the file under market surveillance or operator audit.

Regulatory impact analysis sheet. Typically a one-page front-and-back document, signed by the regulatory engineer, listing for each authority (FCC, ISED, RED, MDR, PTCRB) the proposed classification and its justification. It references the rule sections and harmonised standards affected.
Before/after technical memo. Parameter-by-parameter comparison of pre- and post-modification references: electrical datasheets, RF schematics, Spice or EM simulations as relevant, internal bench measurements. This document often conditions the soundness of the delta tests proposed to the TCB.
Accredited laboratory report. Conformant to standard format (ILAC accreditation header, calibration traceability, DUT identification, ambient conditions). Delta reports referenced against the initial report are accepted by TCBs subject to an explicit coverage analysis statement.
Modification cover letter to the TCB (Class II, Class III). Standardised format in KDB 178919 guidance, indicating the modification type, the list of retained tests, and justification for tests excluded.
Versioned as-built BOM. The ECN cites outgoing and incoming versions. Production cutover is dated.
Reissued RED DoC. Incremented number, dated, referencing the updated Annex V file.

This documentary stack is preserved for ten years for RED and MDR, and at least five years after last manufacture for FCC. Some operator acceptance programs (notably PTCRB) require retention of evidence for the full duration of certificate validity, which can extend beyond regulatory minimums for products kept in service for a decade or more.

Common pitfalls

Pitfall	Consequence	Prevention action
Component substitution without checking radio impact	Class II not filed, FCC enforcement exposure	Mandatory regulatory analysis on every PCN, signed
Firmware update adding an uncovered band	Operation outside authorization, possible grant revocation	Lock regions and bands in build for certified firmware
Treating a firmware update as Class I by default	Under-classification, FCC exposure and RED traceability loss	Analyse measured impact on each initial parameter before decision
Confusing Class III SDR with classical software update	Class III filing rejected for non-SDR product	Verify the initial SDR declaration; otherwise Class II or new application
Failing to notify PTCRB of a modem firmware modification	Operator eligibility removal, US/Canada market block	Include PTCRB systematically in CCB for every cellular product
RED 3.3 security patch introducing a new network function	3.3 re-evaluation skipped, DoC obsolete	Map functions covered by EN 18031; review before push
Not reissuing DoC after RED substantial modification	Archived DoC inconsistent, Article 10(9) breach	DoC numbering linked to BOM, automated at CCB closure
MDR modification without notified-body notification	Missing certificate amendment, possible withdrawal	Written procedure separating significant and non-significant, per IEC 62304 class
Forgetting ISED Canada consistency after FCC filing	Divergent Canada status, importer exposed	Combined FCC + ISED filing through the same TCB/CB
No traced regression test matrix	Cannot demonstrate retained scope under surveillance	Matrix published in every ECR closure, archived ten years

Change management is a cross-functional topic that mobilises engineering, quality and regulatory teams continuously. The spilma glossary gathers the key terms (TCB, CB, KDB, FCC ID, IC, DoC, ECR, CCB, SDR, MDSW, MDCG, MOPP, LPS) with reference definitions.