Conformed to Federal Register Version

Agency decision

Ask Donna

What actually matters in this document.

Text

SECURITIES AND EXCHANGE COMMISSION

17 CFR Parts 232, 239, 249, 269, and 274

[Release Nos. 33-11313; 34-101209; 39-2557; IC-35343; File No. S7-15-23]

RIN 3235-AM58

EDGAR Filer Access and Account Management

AGENCY: Securities and Exchange Commission.

ACTION: Final rule.

SUMMARY: The Securities and Exchange Commission (“Commission”) is adopting rule and

form amendments concerning access to and management of accounts on the Commission’s

Electronic Data Gathering, Analysis, and Retrieval system (“EDGAR”) that are related to certain

technical changes to EDGAR (collectively referred to as “EDGAR Next”). EDGAR Next will

improve the security of EDGAR, enhance filers’ ability to manage their EDGAR accounts, and

modernize connections to EDGAR. The amendments require electronic filers (“filers”) to

authorize and maintain designated individuals as account administrators and to take certain

actions, through their account administrators, to manage their accounts on EDGAR. Further,

pursuant to these amendments, filers may only authorize individuals as account administrators or

in the other roles described herein if those individuals first obtain individual account credentials

in the manner specified in the EDGAR Filer Manual. As part of the EDGAR Next changes,

optional Application Programming Interfaces (“APIs”) will be offered to filers for machine-tomachine communication with EDGAR. Moreover, we are amending Volume I of the EDGAR

Filer Manual to accord with these changes. Filers will have 12 months from the issuance of this

release to transition to EDGAR Next.

DATES: Effective date: The effective date for this rule is March 24, 2025. The incorporation by

reference of certain material listed in this rule is approved by the Director of the Federal Register

as of March 24, 2025.

Compliance date: The compliance date for amended Form ID is March 24, 2025. The

compliance date for all other rule and form amendments (other than the EDGAR Filer Manual

changes) is September 15, 2025. See SUPPLEMENTARY INFORMATION for more

information on compliance and the EDGAR Filer Manual changes.

FOR FURTHER INFORMATION CONTACT: Rosemary Filou, Deputy Director and Chief

Counsel; Daniel K. Chang, Senior Special Counsel; E. Laurita Finch, Senior Special Counsel;

Jane Patterson, Senior Special Counsel; Margaret Marrero, Senior Counsel; Lidian Pereira,

Senior Special Counsel; EDGAR Business Office at 202-551-3900, Securities and Exchange

Commission, 100 F Street NE, Washington, DC 20549.

SUPPLEMENTARY INFORMATION:

The Commission is adopting amendments to 17 CFR 232.10 (“Rule 10”) and 17 CFR

232.11 (“Rule 11”) under 17 CFR part 232 (“Regulation S-T”); and amendments to Form ID

(referenced in 17 CFR 239.63, 249.446, 269.7, and 274.402). The Commission is also adopting

an updated Filer Manual, Volume I: “EDGAR Filing,” Version 42 (issued September 27, 2024)

and amendments to 17 CFR 232.301 (“Rule 301”). The updated Filer Manual is incorporated by

reference into the Code of Federal Regulations.

Table of Contents

INTRODUCTION ................................................................................................................. 5

II.

DISCUSSION ...................................................................................................................... 11

A. Individual Account Credentials ..................................................................................... 13

B. Individual Roles: Account Administrator, User, Technical Administrator ................... 27

1. Account Administrators ............................................................................................ 29

2. Users .......................................................................................................................... 45

3. Technical Administrators .......................................................................................... 48

C. Delegated Entities .......................................................................................................... 53

1. Delegating Authority to File...................................................................................... 54

2. Separation of Authority of Filer and Delegated Entity ............................................. 58

3. Delegated Entities...................................................................................................... 59

4. Delegated Users ......................................................................................................... 61

5. User Group Functionality at Delegated Entities........................................................ 63

6. Technical Administrators at Delegated Entities ........................................................ 65

D. Hours of Operation of the Dashboard ............................................................................ 66

E. Optional Application Programming Interfaces .............................................................. 67

1. APIs That Commission Staff Will Provide ............................................................... 70

2. API Tokens ................................................................................................................ 76

F. Final Amendments to Rules and Forms ......................................................................... 82

1. Rule 10 of Regulation S-T......................................................................................... 82

2. Rule 11 of Regulation S-T......................................................................................... 86

3. Form ID ..................................................................................................................... 89

G. EDGAR Filer Manual Changes ..................................................................................... 98

H. Transition Process ........................................................................................................ 100

1. Enrollment Process .................................................................................................. 108

2. Compliance .............................................................................................................. 117

III.

OTHER MATTERS........................................................................................................... 121

IV. ECONOMIC ANALYSIS ................................................................................................. 122

A. Baseline ........................................................................................................................ 123

B. Consideration of Benefits and Costs as well as the Effects on Efficiency, Competition,

and Capital Formation........................................................................................................ 128

1. Benefits .................................................................................................................... 128

2. Costs ........................................................................................................................ 137

3. Effects on Efficiency, Competition, and Capital Formation ................................... 158

C. Reasonable Alternatives............................................................................................... 159

1. Add and Allow Bulk Confirmation for Related CIKs ............................................. 159

2. Extend the ABSCOMP Process to Affiliated Entities............................................. 160

3. Retire the CCC for Filing Submissions ................................................................... 161

4. Requirements for Individual and Small Filers ........................................................ 162

5. Implementing Performance-Based Standards ......................................................... 164

PAPERWORK REDUCTION ACT .................................................................................. 165

A. Summary of Comment Letters on PRA Estimates ...................................................... 166

B. Form ID ........................................................................................................................ 167

C. The Dashboard ............................................................................................................. 169

VI. FINAL REGULATORY FLEXIBILITY ANALYSIS ..................................................... 172

A. Need for and Objectives of the Rule and Form Amendments ..................................... 172

B. Significant Issues Raised by Public Comments ........................................................... 173

C. Small Entities Subject to the Rule and Form Amendments......................................... 176

D. Projected Reporting, Recordkeeping, and Other Compliance Requirements .............. 179

E. Agency Action to Minimize Effects on Small Entities ................................................ 180

STATUTORY AUTHORITY .................................................................................................... 184

APPENDIX A—FORM ID ........................................................................................................ 194

INTRODUCTION

The Commission is seeking to enhance the security of EDGAR, improve the ability of

filers 1 to securely manage and maintain access to their EDGAR accounts, facilitate the

responsible management of filer credentials, and simplify procedures for accessing EDGAR. 2

In furtherance of these goals, on September 30, 2021, the Commission issued a Request

for Comment on Potential Technical Changes to EDGAR Filer Access and Filer Account

Management Processes (“2021 Request for Comment”). 3 The Commission received comments

in response to the 2021 Request for Comment, 4 and Commission staff subsequently engaged in a

dialogue with commenters and other interested parties, 5 considered feedback from these parties,

and gathered additional information about filers’ interactions with EDGAR. Staff discussed a

variety of topics with commenters including the addition of optional APIs for submission and for

verifying certain information on EDGAR; filers’ annual confirmation of the accuracy of their

account information; whether accession numbers should be traceable to the individuals making

the submissions; bulk submissions and user group functionality; delegation of authority to file; a

potential transition process to implement the contemplated changes; and other technical matters.

After consideration of the information provided by commenters in response to the 2021

Request for Comment, the Commission issued a Proposing Release on September 13, 2023, that

For purposes of this release, we use the term “filer” to mean “electronic filer,” as defined in Rule 11 of

Regulation S-T: “A person or an entity that submits filings electronically pursuant to Rules 100 or 101 of

Regulation S-T.”

For a discussion of the current EDGAR access and account management processes, please refer to EDGAR

Filer Access and Account Management, Release No. 33-11232 (September 13, 2023) [88 FR 65524 (September

22, 2023)] (“Proposing Release”).

For a discussion of the 2021 Request for Comment, please refer to the Proposing Release.

Comment letters related to the 2021 Request for Comment are available at https://www.sec.gov/comments/s712-21/s71221.htm.

Memoranda describing these meetings with SEC officials are available at https://www.sec.gov/comments/s715-23/s71523.htm.

included proposed amendments to Rule 10 of Regulation S-T concerning filer access and

account management and related matters; Form ID, the application for EDGAR access; and Rule

11 of Regulation S-T, containing the definitions of terms in Regulation S-T. The Commission

proposed changes to Rule 10 and Form ID to require each EDGAR filer to authorize and

maintain individual account administrators to manage the filer’s EDGAR account on a dashboard

on EDGAR and to authorize account administrators and other individuals only if those

individuals obtained individual account credentials. The Commission further proposed that each

filer, through its account administrators, be required to confirm annually that the filer authorized

all individuals and delegated entities reflected on the dashboard to act on its behalf, and that all

information about the filer on the dashboard was accurate. The Commission also proposed

requirements to maintain accurate and current information on EDGAR concerning the filer’s

account and securely maintain information relevant to the ability to access the filer’s EDGAR

account. In addition to the proposed rule and form amendments, the Commission described in the

Proposing Release the possible addition of optional APIs to allow machine-to-machine

submissions on and retrieval of certain information from EDGAR and indicated that, to connect

to the optional APIs, filers, through their account administrators, would be required to authorize

at least two technical administrators and present certain security tokens to EDGAR as specified

in the EDGAR Filer Manual.

The Commission considered comment letters received in response to the Proposing

Release that included both comments on the proposed rule and form changes as well as technical

feedback on functionality discussed in the Proposing Release. 6 We considered both the

The public comments we received are available at https://www.sec.gov/comments/s7-15-23/s71523.htm. A few

commenters asserted that the comment period was not sufficient and asked the Commission to extend it. See

comments on the rule and form amendments as well as feedback on EDGAR Next technical

functionality and discuss both aspects together in this release. While we discuss aspects of

EDGAR Next technical functionality in this release together with the final rule and form

amendments, we anticipate that this technical functionality will evolve over time in response to,

for example, changes in filer needs, security requirements, and technological developments,

among other circumstances. As is the case today and has been historically, updates to the

EDGAR system typically will be communicated through the EDGAR Filer Management website

and reflected in amendments to the EDGAR Filer Manual from time to time.

The Commission is adopting the proposed amendments to Rules 10 and 11 of Regulation

S-T and Form ID substantially as proposed. We believe that the rule and form amendments

adopted in this release and the related technical changes further the goals of enhancing the

security of EDGAR access and improving EDGAR account management and are responsive to

the comments received in response to the Proposing Release and the 2021 Request for Comment.

The obligations for filers are generally being codified in Rule 10 of Regulation S-T, new

paragraph (d). 7 Under paragraph (d)(1) of Rule 10 as adopted, only those individuals who obtain

individual account credentials 8 can be authorized to act on the filer’s behalf on the dashboard on

Comment Letter of XBRL US (October 27, 2023) and Toppan Merrill Comment Letter (November 20, 2023)

(“Toppan Merrill Comment Letter”). The comment period for the Proposing Release was open for 60 days, and

we do not believe an extension of the comment period is necessary. Moreover, we have considered all comment

letters received, including those submitted after the comment period closed.

In addition to the changes discussed below, Rule 10 is being amended to implement certain clarifying and

conforming changes. See section II.F.1.

We are amending Rule 11 of Regulation S-T to define “individual account credentials” as credentials issued to

individuals for purposes of EDGAR access, as specified in the EDGAR Filer Manual. See the discussion of

amendments to Rule 11 in section II.F.2. The EDGAR Filer Manual is being amended to specify that individual

account credentials must be obtained through Login.gov, a sign-in service of the U.S. Government that employs

multifactor authentication.

EDGAR. 9 Paragraph (d)(2) of Rule 10 as adopted requires each filer to authorize and maintain

individuals as its account administrators 10 to manage the filer’s EDGAR account on the filer’s

behalf, in accord with the EDGAR account access and account management requirements set

forth in this release and in the EDGAR Filer Manual as it is being amended. Pursuant to the

amendments to Form ID and the EDGAR Filer Manual, the filer can authorize someone who is

not an employee of the filer or its affiliates to be the filer’s account administrator if an authorized

individual for the filer 11 provides a relevant notarized power of attorney. 12 Paragraph (d)(3) of

Rule 10 as adopted requires any filer that decides to connect to an optional API 13 to authorize,

through its account administrators, at least two technical administrators 14 to manage the API

We are amending Rule 11 of Regulation S-T to define the “dashboard” as an interactive function on EDGAR

where electronic filers manage their EDGAR accounts and individuals that electronic filers authorize may take

relevant actions for electronic filers’ accounts. See the discussion of amendments to Rule 11 in section II.F.2. In

connection with this rulemaking, the dashboard will be integrated into the EDGAR Filer Management website,

https://www.filermanagement.edgarfiling.sec.gov.

We are amending Rule 11 of Regulation S-T to define an “account administrator” as an individual that an

electronic filer authorizes to manage the electronic filer’s EDGAR account on EDGAR, and to make filings on

EDGAR on the electronic filer’s behalf. See the discussion of amendments to Rule 11 in section II.F.2.

Applicants (individuals and companies) for EDGAR access must authorize account administrators on Form ID.

See amended Form ID.

We are amending Rule 11 of Regulation S-T to define “authorized individual.” This definition mirrors the

definition of “authorized individual” in the EDGAR Filer Manual, Volume I. See the discussion of amendments

to Rule 11 in section II.F.2 and EDGAR Filer Manual, Volume I.

For example, if a filer wishes to authorize an individual employed by its filing agent to act as the filer’s account

administrator, the filer must upload with the Form ID a power of attorney signed by an authorized individual of

the filer, with that signature notarized, authorizing the employee of the filing agent to be the filer’s account

administrator. See amended Form ID, Part 3. The EDGAR Filer Manual, Volume I sets forth the requirements

for notarization of the signature of an authorized individual. Among other things, pursuant to Volume I of the

EDGAR Filer Manual, notarization may be obtained through a remote online notary recognized by the law of

any State or territory in the U.S. or the District of Columbia.

We are amending Rule 11 of Regulation S-T to define an “Application Programming Interface” or “API” as a

software interface that allows computers or applications to communicate with each other. See the discussion of

amendments to Rule 11 in section II.F.2.

We are amending Rule 11 of Regulation S-T to define a “technical administrator” as an individual that the filer

authorizes on the dashboard to manage the technical aspects of the filer’s use of EDGAR APIs on its behalf. See

the discussion of amendments to Rule 11 in section II.F.2. Technical administrators need not be software

developers or technical experts to carry out the requirements to manage the filer’s use of APIs and filer API

tokens, as discussed more fully below.

unless the filer arranges to use the filer API tokens and API connections of its delegated

entities. 15 Further, the EDGAR Filer Manual is being amended to require that filers present

certain security tokens to connect to the APIs. As adopted, paragraph (d)(4) of Rule 10 will

require each filer, through its authorized account administrators, to confirm annually that all

account administrators, users, 16 delegated entities, 17 and technical administrators reflected on the

dashboard for the filer’s EDGAR account are authorized by the filer and that all information

regarding the filer on the dashboard is accurate. Paragraph (d)(5) of Rule 10 as adopted will

require each filer, through its authorized account administrators, to maintain accurate and current

information about the filer on EDGAR, and paragraph (d)(6) of Rule 10 as adopted will require

each filer, through its authorized account administrators, to securely maintain information

relevant to the ability to access the filer’s EDGAR account.

We are amending Form ID to implement the changes to Rule 10, including but not

limited to the requirement to provide information about the applicant’s account administrators, to

make the form more user friendly, 18 and to improve the utility of the form for Commission

staff. 19 Moreover, we are amending Rule 11 of Regulation S-T to define new terms related to the

See paragraph (d)(3) of Rule 10 as adopted addressing the technical administrator requirements and the

provision therein allowing filers to use their delegated entities’ API connections and filer API tokens so long as

those delegated entities comply with the requirement to maintain two technical administrators.

We are amending Rule 11 of Regulation S-T to define a “user” as an individual that the filer authorizes on the

dashboard to make submissions on EDGAR on the filer’s behalf. See the discussion of amendments to Rule 11

in section II.F.2.

We are amending Rule 11 of Regulation S-T to define a “delegated entity” as an electronic filer that another

electronic filer authorizes, on the dashboard, to file on EDGAR on its behalf. See the discussion of amendments

to Rule 11 in section II.F.2.

As an example of the changes being made to make the form more user friendly, additional instruction will be

added to guide applicants through completion and submission of the form, and the user interface will be

improved.

As an example of the changes being made to improve the utility of the form for Commission staff, a checkbox

will be added to each address field for identification of non-U.S. locations, which will improve data analytics.

rule and form amendments. 20 We are further amending the EDGAR Filer Manual to accord with

the EDGAR Next changes.

The EDGAR Next transition process will begin with the issuance of this adopting release.

For the initial six months, from September 30, 2024 to March 21, 2025, filers may prepare for

the changes by testing in and modifying their internal software systems to accord with an

EDGAR Next Adopting Beta environment reflecting the adopted rule and form amendments and

related technical changes, including but not limited to testing the optional APIs that will be

provided, as well as gathering information necessary to enroll on EDGAR. On Monday, March

24, 2025, a new EDGAR Filer Management website that includes the dashboard will go live, and

related changes in the EDGAR Filer Manual, Volume I will be effective. At that time,

compliance with amended Form ID will be required, all applicants for EDGAR access must

apply on amended Form ID through the dashboard, and the prior version of the form will be

ineffective. If Commission staff grant the amended Form ID application, the filer will be in

compliance with the EDGAR Next changes, and thus will not be required to subsequently enroll

on the dashboard. In addition, beginning Monday, March 24, 2025, existing filers may begin to

enroll on the dashboard, and once enrolled may connect to the optional APIs while still being

able to use the legacy filing process. Compliance with the remaining EDGAR Next changes will

be required on Monday, September 15, 2025, when all EDGAR websites will require, among

other things, Login.gov individual account credentials and dashboard authorization to make

submissions on EDGAR. Filers who have not enrolled by September 15, 2025 will not be able to

make submissions or take other actions in EDGAR other than enroll. Enrollment will be

Please refer to amended Rule 11 of Regulation S-T, set forth in this release, for definitions of the terms used in

the release. The amendments to Rule 11 also update or delete reference to outdated terminology and clarify the

definition of the EDGAR Filer Manual.

permitted for an additional three months, until December 19, 2025. 21 On December 22, 2025,

filers who have not enrolled in EDGAR Next or been granted access through amended Form ID

will be required to submit the amended Form ID through the dashboard to apply for access to

their existing EDGAR accounts. Section II.H below provides additional information regarding

the transition to EDGAR Next.

Additional details regarding EDGAR Next technical changes, including dashboard

functionality and APIs, as well as the transition process are available on the EDGAR Next page

on SEC.gov. 22

II.

DISCUSSION

We are adopting, substantially as proposed, amendments to Rule 10 of Regulation S-T

concerning EDGAR filer access and account management and related matters; Form ID, the

application for EDGAR access; and Rule 11 of Regulation S-T, containing the definitions of

terms in Regulation S-T. We are further amending the EDGAR Filer Manual in accord with the

rule and form amendments. 23 These amendments will, among other things, benefit filers by

improving the security of their EDGAR accounts and making it easier for filers to manage and

maintain access to their EDGAR accounts.

The amendments to Rule 10 and Form ID set forth requirements for each EDGAR filer to

authorize and maintain individual account administrators to manage the filer’s EDGAR account

on a dashboard on EDGAR and to authorize to act on the filer’s behalf only those individuals

In total, the enrollment period will extend nine months, from March 24, 2025 to December 19, 2025. If filers

enroll on the dashboard during this period, they will not be required to apply for access on amended Form ID.

Please see section II.H for additional information about enrollment.

See EDGAR Next-Improving Filer Access and Account Management, U.S. Securities and Exchange

Commission, available at https://www.sec.gov/edgar/filer-information/edgar-next.

A blackline of the changes to Volume I of the EDGAR Filer Manual is available at www.sec.gov/rulesregulations.

who obtain individual account credentials. The EDGAR Filer Manual is being amended to

specify Login.gov as the individual account credential provider. Each filer, through its account

administrators, will be required to confirm annually that all account administrators, users,

technical administrators, and delegated entities reflected on the filer’s dashboard are authorized

by the filer to act on its behalf and that all information regarding the filer on the dashboard is

accurate; maintain accurate and current information on EDGAR concerning the filer’s account;

and securely maintain information relevant to the ability to access the filer’s EDGAR account.

In addition to the rule and form amendments, this release describes the EDGAR Next

functionality that will be offered to filers, including but not limited to optional APIs that will

improve the efficiency and accuracy of filers’ interactions with EDGAR by providing a machineto-machine method of making submissions, retrieving information, and performing account

management tasks. EDGAR will make available 15 optional APIs in total, which include the

three APIs discussed in the Proposing Release and 12 additional APIs, many of which were

requested by commenters. Among other things, these APIs will replicate much of the dashboard

account management functionality, allowing filers to manage their EDGAR accounts with

minimal manual interaction with EDGAR.

If a filer chooses to connect to the optional APIs, the filer, through its account

administrators, must authorize at least two technical administrators, pursuant to paragraph (d)(3)

of Rule 10, unless the filer arranges to use the filer API tokens and API connections of its

delegated entity (and the delegated entity complies with the requirement to maintain at least two

technical administrators), as requested by commenters. Filers choosing to connect to the optional

APIs must also present specified security tokens of limited duration in the form of filer API

tokens and user API tokens, as set forth in the EDGAR Filer Manual as amended. These token

requirements are intended to provide security for API connections. Filers using their delegated

entities’ API connections must use their delegated entities’ filer API tokens, and individuals at

those filers must present a user API token to interact with the APIs to allow identification of the

individual taking action on EDGAR if those APIs require presentation of a user API token.

Filers that do not connect to the optional EDGAR APIs will not need to comply with

these API-related requirements and may continue to make web-based submissions on EDGAR.

Individual Account Credentials

Paragraph (d)(1) of Rule 10 as proposed and adopted will require that a filer only

authorize an individual to perform functions on the dashboard on the filer’s behalf if that

individual possesses individual account credentials, obtained in the manner specified in the

EDGAR Filer Manual. In addition to what was noted in the Proposing Release, however, and in

response to commenter concerns, the EDGAR Filer Manual is being amended to clarify that

individual account credentials may not be shared with other individuals as the credentials are

intended to identify the individual who takes action on EDGAR.

As contemplated in the Proposing Release, we are amending the EDGAR Filer Manual to

specify that individual account credentials must be obtained through Login.gov, a secure sign-in

service of the U.S. General Services Administration. 24 Login.gov is used by participating Federal

agencies, as well as State, local, and territorial governments to provide a secure login process and

to allow members of the public to use a single account that is protected by encryption,

multifactor authentication, and additional safeguards. 25 To obtain individual account credentials

for EDGAR, an individual must respond to prompts on the Login.gov website to provide an

https://www.login.gov/.

See Login.gov, “About us,” at https://www.login.gov/about-us/.

email address, create a password, and select a multifactor authentication option. 26 The EDGAR

Filer Manual will specify that the email address provided to Login.gov must match the email

address the individual has provided or intends to provide to EDGAR (during enrollment, on

amended Form ID, or to the relevant account administrator). 27

In accord with amended paragraph (d) of Rule 10 and the EDGAR Filer Manual, and as

proposed, all account administrators, users, and technical administrators must enter their

individual account credentials and complete multifactor authentication to log into EDGAR. After

entering the email address and the password created on Login.gov, the individual will be

prompted to complete the multifactor authentication option the individual selected when

obtaining individual account credentials at Login.gov. 28 Thus, through Login.gov, multifactor

authentication for individual accounts will be required to access EDGAR.

The use of multifactor authentication aligns with modern security practices, such as those

set forth in Executive Order No. 14028, issued May 12, 2021, directing Federal agencies to

modernize and implement stronger cybersecurity standards (“executive order”), 29 including but

As of the date of this release, Login.gov multifactor authentication options include: (1) a security key; (2)

Federal government employee or military PIV or CAC cards; (3) authentication application; (4) biometric (face

or fingerprint) verification; (5) text message/SMS or telephone call; and (6) backup codes. With respect to

option (3), current Login.gov authentication applications include: Android and iOS options (Google

Authenticator, Authy, LastPass, 1Password), Windows and Mac apps (1Password and OTP Manager), and

Chrome extensions (Authenticator). See generally Login.gov, Authentication Options at

https://www.login.gov/help/get-started/authentication-options/. See also generally Login.gov, “Privacy and

security: Our security practices,” at https://login.gov/policy/our-security-practices/ for information on

If an individual changes the email address that she uses in connection with EDGAR (for example, because of a

change of domain name), the individual should first change her email address on the dashboard and then change

it on Login.gov. This will prevent interruptions in access to EDGAR. If an individual permanently loses access

to her email before taking the steps above, the individual should create another account on Login.gov with a

new email address, and the filer’s account administrator should add her to the filer’s account on the dashboard

using the new email address.

If the individual loses or forgets her Login.gov password, the individual can reset the password through

See Exec. Order No. 14028 (2021), 60 FR 26633, 26636 (May 17, 2021).

not limited to the deployment of multifactor authentication as a foundational security tool at

Federal agencies. As stated in the executive order, the use of multifactor authentication enhances

system security. It further follows digital identity guidelines for Federal agencies issued by the

National Institute of Standards and Technology (“NIST”). 30 Multifactor authentication is a

widely accepted security tool that will improve the security of access to EDGAR by adding a

layer of validation each time an individual signs into EDGAR.

In sum, EDGAR Next will enhance the security of filers’ accounts by requiring anyone

seeking to make a submission on EDGAR on behalf of a filer to sign in with individual account

credentials, complete multifactor authentication, be authorized by the filer or the filer’s account

administrator and enter the filer’s EDGAR account/central index key number (“CIK”) and

central index key confirmation code (“CCC”).

Commenters generally agreed that requiring individual account credentials for EDGAR

access would improve EDGAR security, provide individual accountability and, by implementing

multifactor authentication, align EDGAR with current best practices. 31

Several commenters expressed concerns that the introduction of individual account

credentials could be disruptive or unduly burdensome for individuals with reporting obligations

See Digital Identity Guidelines: Authentication and Lifecycle Management, National Institute of Standards and

Technology, NIST SP 800-63, available at https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final, at section 4 of

NIST SP 800-63B (“Any PII or other personal information — whether self-asserted or validated — requires

multi-factor authentication.”).

See, e.g., Comment Letter of Cory (September 19, 2023) (“Cory I Comment Letter”) (“[This is] essential to

verify the identity and legitimacy of those managing financial data, mitigating the risk of unauthorized access

and fraud”); Comment Letter of XBRL US (November 21, 2023) (“XBRL II Comment Letter”) (“Multi-factor

authentication is a step forward in increasing EDGAR security and has become a standard for most

companies.”); Comment Letter of Block Transfer (November 21, 2023) (“Block Transfer Comment Letter”)

(“We agree with the [Commission’s] position that individual accountability through people-based, not

organization-wide, accounts will lead to greater accountability, transparency, and efficiency in the market”).

pursuant to section 16 of the Securities Exchange Act of 1934 (“Exchange Act”). 32 For the

reasons discussed below, we do not think that the issues raised by these commenters will be

disruptive or unduly burdensome for section 16 filers. One commenter asserted that many

individuals use Login.gov for personal matters and suggested that these individuals may not wish

to use their existing Login.gov accounts for EDGAR matters. 33 The EDGAR Filer Manual as

amended will require individuals to present an email address that matches the email address the

individual will use in connection with EDGAR 34 to obtain Login.gov individual account

credentials for EDGAR. 35 The email address will become the individual’s username for

purposes on EDGAR. Therefore, if an individual currently has a Login.gov account created with

her personal email address and does not intend to use that email address in connection with

EDGAR matters, or is otherwise concerned that her personal email address may become visible

on the EDGAR Filer Management dashboard, she should create new Login.gov individual

account credentials with the email address she wishes to use in connection with EDGAR. 36 This

See, e.g., Comment Letter of Society for Corporate Governance (August 30, 2024) (“SCG Comment Letter”)

(“[I]t appears that some companies have assumed their third-party filing agents would handle this major

EDGAR overhaul without significant disruption or additional work by in-house personnel. However, the

comment letters by filing agents and other vendors suggest otherwise.”); XBRL II Comment Letter (“[W]e do

not believe the rule proposal adequately addresses the needs of Section 16 filers and single individual filers

[who] will perform their own code management.”).

See SCG Comment Letter (“[T]here was also concern with respect to the fact that Login.gov is used, in many

instances, for individuals’ personal matters (e.g., Social Security). Using a single account for both personal and

public filings is likely to lead to confusion and hesitation on the part of the Section 16 filers. Such individuals

may not wish to comingle their personal matters with their public filing obligations.”).

Individuals will provide their email addresses on Form ID, during enrollment, and to account administrators to

identify themselves. The dashboard will display individuals’ email addresses for identification and individuals

will receive email notifications from EDGAR at their email addresses. Therefore, individuals should present to

EDGAR, and that they will use to receive communications from EDGAR.

See amended EDGAR Filer Manual, Volume I, at section 3(a).

By contrast, if individuals currently have Login.gov accounts used in connection with EDGAR, they may

choose to rely upon those existing Login.gov individual account credentials.

email address could be the one provided to the individual by her employer or that the individual

uses for business purposes. Individuals can continue to use their Login.gov personal email

address and password for personal matters. They will separately use the Login.gov individual

account credentials they created for use on EDGAR to log into EDGAR.

Several commenters further suggested that it would be a burden on section 16 filers to

apply for EDGAR access and to enroll in EDGAR Next themselves and requested that EDGAR

permit a corporate secretary or legal personnel of a registrant to obtain EDGAR access for an

individual section 16 filer pursuant to a power of attorney. 37 In response to these comments, we

clarify that EDGAR will permit this. Individuals with individual or single-member company filer

EDGAR accounts may avoid obtaining Login.gov individual account credentials for EDGAR if

they authorize an individual at their filing agent or other third party to enroll them in EDGAR

Next and during enrollment authorize one or more individuals at these entities to act as their

account administrators. 38 For enrollment, presentation of a power of attorney for the person

performing enrollment or being authorized as an account administrator will not be necessary,

although we urge all filers to carefully coordinate regarding the person they will authorize to

enroll them. For enrollment, the codes required to be entered will act as validation of the filer’s

intent. 39

See, e.g., SCG Comment Letter (“We believe that the corporate secretary or legal personnel of the registrant –

with a Power of Attorney (POA) – should be able to complete the process for obtaining EDGAR access codes

or passphrases without further involvement from an individual Section 16 filer.”); XBRL II Comment Letter

(“[W]e do not believe the rule proposal adequately addresses the needs of Section 16 filers and single individual

filers will perform their own code management.”).

Only one individual (the individual need not be an account administrator so long as the filer authorizes the

individual to enroll) would enroll the filer, providing information about authorized account administrators

during enrollment. After enrollment, the account administrators would manage the filer’s account on the

dashboard, adding account administrators, users and technical administrators, if connecting to APIs, and

delegating authority to file, if relevant.

See infra text accompanying and following note 208 (the filer’s CIK, CCC, and EDGAR passphrase must be

provided to validate the enrollment request as legitimate).

Separately, individual or single-member company filers who apply for access on

amended Form ID may authorize one or two individuals at their filing agents or relevant

companies as their account administrators on Form ID; however, for Form ID, individual or

single-member company applicants must also provide signed, notarized powers of attorney to

those persons to be uploaded to EDGAR together with the completed Form ID. Thereafter, the

filer’s authorized account administrators would obtain individual account credentials from

single-member company filer would not need to obtain Login.gov individual account credentials

in these circumstances.

The commenter also expressed concerns regarding how section 16 filers and others would

navigate the multifactor authentication process when making filings. 40 As an initial matter, we

do not believe that it will be difficult for section 16 filers and other individuals to navigate the

by numerous financial and other websites for verification. It is therefore likely that section 16

filers and other individuals have experience in performing multifactor authentication.

Alternatively, as discussed above, section 16 filers and other individual filers may provide

notarized powers of attorney to authorize account administrators to manage filers’ accounts and

make submissions on filers’ behalf, eliminating the need for section 16 filers and other individual

filers to obtain individual account credentials or perform multifactor authentication themselves. 41

See SCG Comment Letter (“[Our members] expressed concerns about how registrants, Section 16 insiders, and

their filing agents would navigate the new MFA process when making filings.”).

See sections II.B.1 and II.B.2.

The commenter further raised issues surrounding the security of Login.gov. 42 The matters

raised by the commenter pertain to Login.gov’s provision of identity assurance level 2 (“IAL2”)

services, 43 which generally require gathering certain sensitive personally identifiable information

such as copies of drivers’ licenses, passports, or similar documents. EDGAR’s agreement with

require presentation of such sensitive personally identifiable information. To obtain individual

account credentials from Login.gov for EDGAR, the individual need only provide her email

address, create a password, and select a multifactor authentication method. The security of

numerous Federal and State agencies successfully use Login.gov on an ongoing basis.

Other commenters suggested that EDGAR provide filers with the option to continue to

use a password and CCC instead of Login.gov during a transition period to EDGAR Next. 44 In

response to these comments, we clarify that from March 24, 2025 to September 12, 2025,

EDGAR will continue to allow submissions to be made when the password and CCC are

presented. One commenter asked that the Commission allow section 16 filers to continue to log

See SCG Comment Letter (“Given that the security of Login.gov has been questioned by Congress and the

Internal Revenue Service has expressed reservations about using the platform, the Commission should not

mandate Login.gov as the sole platform that registrants and their Section 16 filers may use for multi-factor

authentication.”).

See “GSA Misled Customers on Login.gov’s Compliance with Digital Identity Standards,” Press Release,

Office of the Inspector General, U.S. General Services Administration, available at

https://www.gsaig.gov/content/gsa-misled-customers-logingovs-compliance-digital-identity-standards (“GSA

knowingly billed IAL2 customer agencies over $10 million for services, including alleged IAL2 services that

did not meet IAL2 standards.”)

See, e.g., Comment Letter of Donnelley Financial Solutions (May 8, 2024) (“DFIN II Comment Letter”) (“[W]e

encourage the Commission to consider supporting the current authentication method for an overlapping period

of time as an alternative during the EDGAR Next roll out. This will help with the transition and minimize

market disruption.”); SCG Comment Letter (“We agree with DFIN’s suggestion that registrants and their

Section 16 filers should be allowed to use current authentication methods during the transition to EDGAR Next

to minimize disruptions or filing delays.”)

into EDGAR under the existing process for six months after enrollment ends. 45 We are offering

the legacy filing process for six months from March 24, 2025 through September 12, 2025,

during which time filers may also enroll. In addition, we are allowing filers to continue to enroll

on the dashboard for an additional three months after the compliance date. 46 The 12 months that

precede compliance, consisting of six months to prepare for the changes and six months to enroll

while legacy filing processes continue, plus an additional three months after compliance to

enroll, effectively operate as a phased-in implementation of the new requirements, and permits

filers multiple means of accessing EDGAR, while they coordinate with their filing agents and

other relevant parties regarding how they will manage their accounts, and ensures timely

compliance. 47 We considered comments regarding offering the legacy filing process beyond the

transition period, but we determined that doing so would increase the risk of EDGAR security

issues arising by delaying the implementation of, among other things, multifactor authentication

and individual account credentials. 48

Several commenters suggested that filers should have the option to use alternatives to

See SCG Comment Letter (“We also ask that the Commission consider allowing all Section 16 filers to continue

to use the existing EDGAR system for an additional six months after the enrollment period ends, so they do not

miss any deadlines while the enroll in EDGAR Next.”) (emphasis in original).

Further, the commenter appeared to base the comment in part upon the assumption that there would be a onemonth preparation period prior to enrollment in EDGAR Next. Instead, the Commission is offering filers a sixmonth preparation period which we believe will allay the commenter’s expressed concerns.

See SCG Comment Letter (“[t]he Commission has prudently provided phased-in implementation for other rules,

such as for XBRL tagging and the Form 8-K cybersecurity incident disclosure rules, and we believe that a

phased-in approach makes sense given the hundreds of corporate directors who may have to obtain Login.gov

accounts and then enroll through the EDGAR Next dashboard.”).

In addition, it is not technically feasible for EDGAR to extend legacy filing processes for one subset of filers.

See DFIN II Comment Letter (“We continue to believe that Edgar filers should have the optionality to use

alternatives to Login.Gov as technology offerings evolve.”); Comment Letter of the Investment Company

Institute (September 11, 2024) (“ICI Comment Letter”).

the event the service is unavailable but did not suggest what alternatives were appropriate. 50

Another commenter approved of the choice of Login.gov. 51 Login.gov is a secure Federal sign-in

service that aligns with the modern security practices set forth in the executive order and follows

the digital identity guidelines for Federal agencies issued by NIST, as indicated above. Using a

single secure sign-in service strengthens the ability of Commission staff to monitor, identify, and

address login issues related to EDGAR. It also increases efficiency in terms of EDGAR and filer

programming, maintenance and customer support and ensures that individuals attempting to

access EDGAR are able to achieve similar experiences in the login process. Moreover, we are

not aware of any recurrent Login.gov outage issues that necessitate implementing additional

Federally accepted tools. If in the future it is possible to meet the Commission’s goals of

individual traceability and multifactor authentication with improved alternative technology, that

technology will be considered as appropriate. EDGAR will be able to substitute or add other

methods of obtaining individual account credentials and completing multifactor authentication if

it is beneficial to do so. If the Commission determines to change or add methods of

authentication to EDGAR, we would inform filers in advance and specify the changes in the

EDGAR Filer Manual.

Some commenters raised concerns that requiring individual account credentials for

EDGAR access could be burdensome and confusing in specific situations, such as where

See SCG Comment Letter (“There will be busy filing periods, such as 40 days after the end of a fiscal quarter

when larger companies make their periodic filings, where it would be helpful to have alternative platforms for

authentication in case Login.gov is not available.”).

See Toppan Merrill Comment Letter (“Login.gov is a good choice for EDGAR access since it was created and

is maintained by the federal government. It is already utilized by other government agencies and some public

users.”).

individuals sit on multiple boards of different issuers, or an individual retires or is terminated. 52

The use of individual account credentials and multifactor authentication is a widely used account

management process. While we acknowledge that requiring individual account credentials

imposes some additional burden in that it interposes a new step in the EDGAR access process,

we do not believe that requiring individual account credentials will be unduly burdensome or

confusing because the use of individual user permissions is a standard practice in software

applications and computer systems. Moreover, certain examples cited by commenters appear to

stem from some confusion regarding dashboard authorization as it pertains to individual account

credentials.

Several commenters raised concerns about specific scenarios involving individual

account credentials, such as when an individual the filer has authorized to act on her behalf

retires or is terminated, 53 or when an individual sits on multiple boards. 54 In the first scenario, an

account administrator would be able to remove the authorization of an individual on the

dashboard, at which point the individual could no longer use her individual account credentials

to access the filer’s account. In the second scenario, an individual who sits on multiple boards

would be able to make submissions on any of her EDGAR accounts in several different ways.

First, the individual need not obtain Login.gov individual account credentials or interact with the

dashboard at all if she authorized one or more individuals employed at her filing agents or other

relevant companies as her account administrators (up to a total of 20) with notarized powers of

See, e.g., XBRL II Comment Letter (discussing situations involving individual filers who sit on multiple boards

of different issuers); Comment Letter of Workiva (November 20, 2023) (“Workiva Comment Letter”) (noting

that individual account credentials must be managed at an individual level, which could cause problems for

filers if individuals retire or are terminated).

See Workiva Comment Letter.

See XBRL II Comment Letter.

attorney, as discussed above. Second, she could log into the dashboard and delegate to her filing

agents and other relevant companies the authority to make submissions on her behalf. Third, the

individual could log into the dashboard and authorize account administrators or users of her

choice to make submissions on her behalf. Fourth, she could be her own account administrator or

user and log into the dashboard with her individual account credentials and make submissions.

We further note that for enrollment, she can authorize individuals as her account administrators

without presenting a notarized power of attorney, although we advise section 16 and other filers

to carefully plan whom they authorize to enroll them in EDGAR Next. Once a filer has

authorized account administrators, the account administrators would make submissions on the

filer’s behalf and otherwise manage the account and perform annual confirmation. Given these

various options and solutions, we do not believe that the final amendments’ requirements are

onerous.

Commenters also asserted that individual account credentials would not guarantee

EDGAR security, since for example individuals could intentionally share their individual

account credentials with unauthorized persons or EDGAR could be otherwise compromised. 55

We acknowledge that requiring individual credentials will not entirely remove threats to EDGAR

security, but mandating such credentials will improve the overall security of the EDGAR system.

For example, even if the individual account credentials were shared, Commission staff and filers

would know whose credentials were shared. Moreover, the use of individual account credentials

that employ multifactor authentication complies with current best practices for information

See, e.g., Workiva Comment Letter (stating that delegated entities may try to share individual account

credentials for a single individual among various employees at the delegated entity); XBRL II Comment Letter

(noting that multifactor authentication would protect the Filer Management dashboard but would not stop

malicious entities who somehow obtained the filer’s filer API token and user API token from using those

tokens).

security at U.S. Federal agencies, such as those described in the executive order and the NIST

digital identity guidelines.

Individual account credentials will enhance the ability of filers to securely maintain

access to their EDGAR accounts. Filers currently share access codes among multiple individuals,

making it difficult to track with whom the codes are shared or to trace a filing to a specific

individual. The use of individual account credentials should enable Commission staff and those

with filing obligations to determine more easily the individuals making specific filings on

EDGAR, because the person-specific nature of the credentials coupled with the individual’s

multifactor authentication will identify individuals associated with EDGAR actions--unlike

access codes, which are tied to a particular EDGAR account rather than to an individual. 56

Linking individuals to the filings they make will be particularly useful for Commission staff and

filers when problematic filings are made on EDGAR and will enhance the security and integrity

of the system. Thus, for example, without individual account credentials, if an EDGAR filing is

submitted that appears on its face to be materially misleading, Commission staff and the filer

may confer about the contents of the filing, but it may be difficult for them to ascertain who

submitted it given that the filer may have widely shared its access codes.

To address the concern that security may be compromised by individuals intentionally

sharing their individual account credentials with unauthorized persons, 57 we are amending the

EDGAR Filer Manual to clarify that individual account credentials may not be shared with other

individuals. The Commission intends that individual account credentials identify the individual

who takes action on EDGAR and sharing of credentials defeats that goal. In addition, the sharing

See amended EDGAR Filer Manual, Volume I, at section 3(a).

See, e.g., Workiva Comment Letter (stating that delegated entities may try to share individual account

credentials for a single individual among various employees at the delegated entity).

of individual account credentials among multiple individuals undermines the purpose of

multifactor authentication, which is intended to be specific to a known individual.

Use of individual account credentials also will provide additional assurance that only

individuals who have been properly authorized by the filer can take actions on the filer’s behalf

on EDGAR. Currently, filers’ interactions with EDGAR require the use of several codes.

Because individual account credentials will be used to authenticate individuals accessing

EDGAR pursuant to Rule 10 as amended, the EDGAR password, password modification

authorization code (“PMAC”), and passphrase will not be needed to make submissions after the

compliance date, as discussed in section II.H. 58 The historic use of several codes with differing

functions is not in accord with current industry best practices. The use of individual account

credentials aligns more closely with modern access processes, including multifactor

authentication, as set forth in the executive order and the NIST guidelines discussed above.

The CCC will continue to function as the code required for filing, but those seeking to

make submissions will also need to sign in with individual account credentials, complete

multifactor authentication, and be authorized by the filer or an account administrator for the filer.

Because of these additional safeguards, the filer’s CCC will be displayed on the dashboard for

account administrators and users.

One commenter suggested eliminating the CCC as unnecessary given the requirement to

authorize individuals through the dashboard. 59 In addition to dashboard authorization, EDGAR

will continue to require the CCC to provide additional security, for example, to complement API

Filers enrolling during the three-month period after the compliance date will be required to present the CIK,

CCC, and passphrase to complete enrollment.

See Comment Letter of the Securities Industry and Financial Markets Association (“SIFMA Comment Letter”)

(“[I]t would seem that by granting authority to the agent through EDGAR Next, there would not be a need for

the CCC.”).

tokens, as well as to avoid the need to make additional infrastructure and form changes to

EDGAR at this time. To maintain the CCC in a secure environment and remove the need for a

filer to email or circulate the CCC, the CCC will appear on the dashboard of individuals

authorized to make submissions for the filer. 60 The CCC may be eliminated in the future if

feasible from a technical and security standpoint.

One commenter indicated that certain Login.gov multifactor authentication methods are

restricted in certain countries. 61 While we understand that not all the methods for multifactor

authentication on Login.gov may be available to those in certain countries, we note that

certain Federal Government employee or military cards, authentication applications, biometric

(face or fingerprint) verification, text message/SMS or telephone call, and backup codes. Further,

there are several authentication applications accepted by Login.gov. 62 Individuals need only

choose one method available to them. Therefore, we expect that filers in such countries will be

able to choose an alternative method on Login.gov to satisfy the multifactor authentication

requirement.

Another commenter asserted that in lieu of individual account credentials and multifactor

authentication, as contemplated in the Proposing Release, Login.gov should allow EDGAR

Specifically, this will include the filer’s account administrators, users, delegated administrators, and delegated

users.

See SCG Comment Letter (“In addition, some features of Login.gov (e.g., text or voice MFA options) are

restricted in certain countries, which could impose an added burden on filers based outside the United States.”).

Current Login.gov authentication applications include Android and iOS options (Google Authenticator, Authy,

LastPass, 1Password), Windows and Mac apps (1Password and OTP Manager), and Chrome extensions

(Authenticator). See generally Login.gov, Authentication Options at https://www.login.gov/help/getstarted/authentication-options/.

authentication via EDGAR Next API keys. 63 API keys alone, however, do not provide the

security assurances of multifactor authentication.

Individual Roles: Account Administrator, User, Technical Administrator

Paragraph (d)(2) of Rule 10 as proposed and adopted requires each filer to authorize and

maintain at least two individuals with individual account credentials as account administrators to

manage the filer’s EDGAR account and to make submissions on EDGAR on behalf of the filer,

unless the filer is an individual or single-member company, 64 in which case the filer will be

required to authorize and maintain at least one individual with individual account credentials as

an account administrator. 65

Account administrators, acting on behalf of the filer, may authorize and de-authorize

individuals with individual account credentials as users, additional account administrators, or

technical administrators for the filer, as needed, using the dashboard (or the optional APIs that

will enable filers to access much of the dashboard’s functionality via machine-to-machine

connections). 66 This process is illustrated in diagram 1 below.

See Block Transfer Comment Letter (“[W]e respectfully submit to the Commission that Login.gov might

present material benefits to issuers if it replaced the proposed security interface using EDGAR Next API

keys.”).

As defined in amended Rule 11 and amended Form ID, a “single-member company” will be a company that has

a single individual who acts as the sole equity holder, director, and officer (or, in the case of an entity without

directors and officers, holds position(s) performing similar activities as a director and officer).

Minor revisions to paragraph (d)(2) as proposed were made to the paragraph as adopted to clarify that each

individual or single-member company electronic filer must authorize and maintain at least one individual as an

account administrator to manage its EDGAR account.

See the EDGAR Next page on SEC.gov for guidance regarding actions on the dashboard.

An individual could be authorized to perform more than one role for a filer. For example,

one individual could be both an account administrator and a technical administrator, or one

individual could be both a technical administrator and a user. An account administrator could not

be a user, however, because account administrators can perform all the functions of a user

themselves, including making submissions on EDGAR. Analogous roles will exist at delegated

entities. The key functions that could be performed by each role are illustrated in diagram 2

below.

Diagram 2: Key Functions for each Role

Role

Account

Administrator

User

Manage

account

administrators,

Submit

users, technical

filings, Generate/ administrators,

view

change

and delegated

CCC

entities

Delegate

another

filer

Manage Manage

Manage

filer

user

delegated

API

users

token

Technical

Administrator

Delegated

Administrator

Delegated

User

Account Administrators

Paragraphs (d)(4), (5), and (6) of Rule 10 as proposed and adopted require that the filer,

through its account administrators, maintain accurate and current information on EDGAR

concerning the filer’s account and confirm such information annually, and securely maintain

information relevant to the ability to access the filer’s EDGAR account, including but not limited

to access through optional APIs. Commenters broadly supported the implementation of account

administrators to manage filers’ accounts, 67 although commenters raised concerns about specific

issues as discussed below.

Under EDGAR Next, each filer will be responsible, through its account administrators,

for the security of the filer’s EDGAR account and the accuracy of the filer’s information on

EDGAR. Account administrators will manage the filer’s account on the dashboard or through

optional APIs replicating most dashboard functionality in machine-to-machine connections. The

filer will be required, through its account administrators, to perform annual confirmation on the

dashboard. Account administrators will also be able to use the dashboard or optional APIs to add

and remove users, account administrators and technical administrators (including removing

themselves as an account administrator); create and edit groups of users; delegate filing authority

See, e.g., Cory I Comment Letter (“One of the cornerstones of EDGAR Next is the requirement for filers to

designate account administrators…. In an era of machine-driven manipulation, this human oversight is crucial

for detecting and preventing illicit activities.”); Toppan Merrill Comment Letter (“Yes, a required account

Administrator [sic] role is necessary for every filer (every CIK). Ideally two Administrators [sic] should be

required.”).

to other EDGAR accounts and remove delegation; generate a new CCC; and receive

notifications regarding significant events affecting the account (notifications will also be emailed

to the account administrator’s email address provided to EDGAR). Further, account

administrators will be able to make submissions on behalf of the filer on EDGAR, which will

allow filers to manage their accounts and make submissions through a limited number of

individuals, if they choose. Each account administrator will be co-equal, possessing the same

authority and responsibility to manage the filer’s EDGAR account. All actions required to be

performed by account administrators can be performed by any of them individually and will not

require joint action.

In addition, account administrators will serve as the points of contact for questions from

Commission staff regarding the filer’s account. 68 One commenter suggested that existing filers

with a single EDGAR point of contact for information, inquiries, and access codes (“EDGAR

POC”) typically rely upon legal staff, whereas under EDGAR Next those filers may choose to

authorize, for example, services staff as account administrators. 69 The commenter stated that the

EDGAR POC for existing filers should be automatically enrolled as a “super administrator” for

the filer and notified regarding significant events affecting the account. 70 Because filers may

wish to designate a single account administrator as a primary EDGAR POC, EDGAR will offer

an option to allow account administrators to designate one account administrator as the filer’s

EDGAR POC. EDGAR will by default designate the first account administrator listed on Form

Technical administrators will serve as the Commission staff’s points of contact regarding the filer’s use of the

APIs. See infra section II.B.3.a.

See Workiva Comment Letter (“The current POC is likely a different type of staff, such as legal staff, from the

administrators who are likely to be reporting or services staff.”).

See Workiva Comment Letter (“We further suggest automatically enrolling the current POC as super

administrator. The super administrator should be contacted before any severe action on the EDGAR account is

taken, such as account deactivation.”).

ID or an existing filer’s enrollment as the filer’s EDGAR POC. The filer, through its account

administrator, may change its EDGAR POC thereafter on the dashboard. Commission staff may

contact the filer’s other account administrators if, for example, the EDGAR POC cannot be

reached or is nonresponsive. The EDGAR POC will not be a “super administrator,” as suggested

by the commenter, however, and each account administrator will have co-equal authority to take

action on EDGAR as well as to receive notices of actions on the filer’s account. Other than

acting as a central point of contact, the EDGAR POC will not differ in any other respect from

other account administrators.

Several commenters stated that the dashboard should provide a mechanism for authorized

users or other interested parties to easily identify and contact the filer’s account administrators. 71

The dashboard will be enhanced to provide this functionality. In this regard, account

administrators will also serve as points of contact for technical administrators, users and

delegated entities.

Filer Authorization of Account Administrators

As proposed and adopted, applicants for EDGAR access will designate on amended Form

ID the individuals that the filer authorizes as account administrators. 72 Pursuant to paragraph

(d)(1) of Rule 10 as proposed and adopted, the filer can only authorize individuals as account

administrators if those individuals obtain individual account credentials in the manner specified

in the EDGAR Filer Manual. We are adopting the amendments to Form ID largely as proposed,

as discussed in section II.F.3. In response to commenter concerns, however, it will not be

See, e.g., XBRL II Comment Letter (“There should be a mechanism in the filing management dashboard where

the company (e.g. technical admin) can identify and contact their administrators...”); Workiva Comment Letter

(“[A] a user may not necessarily know who the administrators are to contact. We suggest adding a “Contact

Administrator” function in the EDGAR Dashboard to facilitate.”).

A separate process of enrollment will be employed to transition existing filers, as discussed in section II.H.

necessary for Form ID to be completed or submitted by one of the applicant’s prospective

account administrators, as contemplated in the Proposing Release. This change will allow a filer

to choose who will complete and submit Form ID so long as the filer complies with the

continued requirement that the form be signed by the filer’s authorized individual, as that term is

defined in Rule 11 of Regulation S-T and Volume I of the EDGAR Filer Manual, and that the

signature is notarized. Additionally, given commenter concerns that asset-backed securities

(“ABS”) issuing entities that make “Request Asset-Backed Securities (ABS) Issuing Entities

Creation” submissions (“ABSCOMP” submissions”) should have their account information

automatically copied to any serial companies, EDGAR will allow for new serial companies

requested to be created via the ABSCOMP process to automatically inherit all dashboard

information associated with the ABS issuing entity that made the ABSCOMP submission.

Consistent with current requirements, an applicant must complete Form ID and

electronically submit it, and also upload a copy of the completed Form ID signed by an

authorized individual of the applicant with the signature notarized. As a departure from what we

contemplated in the Proposing Release, it will not be necessary for Form ID to be completed or

submitted by one of the applicant’s prospective account administrators. Some commenters were

concerned that requiring an account administrator to complete and submit Form ID would be

burdensome and unnecessarily restrictive. 73 We understand that providing flexibility in terms of

who completes and submits Form ID will facilitate the application process.

As contemplated in the proposal, entity applicants will be able to authorize as account

See, e.g., Comment Letter of Donnelley Financial Services (November 21, 2023) (“DFIN Comment Letter”)

(“[In addition to account administrators,] any “User” should also be allowed to submit a Form ID. The account

administrator(s) might be busy, unavailable, or decide it’s a menial task.”); Workiva Comment Letter (“[I]t is

not necessary to require an account administrator to submit the Form ID. A user should also be able to submit

the Form ID. The Form ID is already required to be signed and notarized by authorized personnel…. A user is

adequate for submission.”).

administrators either (i) individuals employed at the filer or an affiliate of the filer or (ii) any

other individual provided the filer submits a notarized power of attorney authorizing that

individual to be its account administrator. 74 Individual applicants will be able to authorize as

account administrators either (i) themselves or (ii) any other individual provided the filer submits

a notarized power of attorney authorizing that individual as account administrator. Commenters

provided mixed feedback on this issue, with one supporting the notarization requirement as

contemplated in the proposal; another advancing that the requirement should not apply to

employees of affiliates; and another expressing concern that the notarization requirement as a

whole would be unduly burdensome. 75 Although we acknowledge the added time and effort

required to obtain a notarized power of attorney, the process is relatively straightforward,

analogous to the current process of notarization of the authorized individual signature on Form

ID, and not unduly time consuming. Moreover, the process will provide greater assurance that a

filer indeed intends to authorize an individual not employed at the filer or an affiliate of the filer

to manage the filer’s EDGAR account. We therefore are implementing the notarized power of

attorney requirements as proposed, and the amended Form ID and EDGAR Filer Manual will

reflect those requirements.

A commenter questioned why the requirement to present a notarized power of attorney to

authorize an employee of an entity other than the filer as account administrator on Form ID is

needed when authorization of additional account administrators through the dashboard does not

The amended EDGAR Filer Manual specifies that an “authorized individual” must sign a power of attorney on

behalf of the filer in this context. See amended EDGAR Filer Manual, Volume I, at section 3.

See, e.g., Toppan Merrill Comment Letter (“We support the proposal to have the initial account administrator

require a notarized power of attorney, if applicable.”); DFIN Comment Letter (“[I]f the account administrator is

an employee of the filer’s affiliate, they should not be required to be authenticated via a notarized power of

attorney.”); Workiva Comment Letter (“We believe that a notarized power of attorney should not be required to

add an employee of another entity as an administrator. This could significantly increase the burden for the

individual reporting owners….”).

require notarization. 76 The requirement to present a notarized power of attorney to authorize

individuals who are not employed at the applicant or an affiliate as account administrators on

Form ID provides Commission staff – who review each Form ID to determine whether access

should be granted – a means of confirming that these individuals are indeed authorized on behalf

of the applicant. The requirement lessens the risk that unauthorized persons will attempt to

establish or access an account by submitting a false or misleading Form ID. We did not include a

notarization requirement for account administrators added through the dashboard, because once

Commission staff grant access to EDGAR, filers are responsible, through their account

administrators, for the security of the filer’s EDGAR account and the accuracy of the filer’s

information on EDGAR. Filers can take the additional steps they determine are necessary to

comply with the Rule 10 and EDGAR Filer Manual requirements to secure their accounts.

We also received several comments regarding the authorization of account administrators

in situations unique to specific types of filers. One commenter recommended that account

administrators associated with ABS issuing entities that make ABSCOMP submissions should

automatically be copied to any serial companies created as a result of that submission, and

another commenter suggested that all account information associated with the ABS issuing entity

should be automatically copied over to the newly created serial companies. 77 Up to 100 serial

companies can be created via a single ABSCOMP submission, and we recognize that it would be

time consuming to require identical addresses, account administrators, and other information to

See Workiva Comment Letter (“In addition, since the power of attorney is only needed initially, and once an

administrator is added to the EDGAR Dashboard additional administrators can be added without a new power

of attorney; it seems inconsistent and somewhat arbitrary that there is a higher threshold for the first one.”).

See DFIN Comment Letter (“[T]he Account Administrator and information from the ABS Issuer’s Account

Administrator should be copied to the new serial account, after which, any changes can be made.”);

Cadwalader, Wickersham & Taft LLP Comment Letter (November 21, 2023) (“Cadwalader Comment Letter”)

(“For [commercial mortgage-backed securities] issuers, allowing automatic inheritance by the individual serial

trusts of all information from the depositor would be the most efficient approach.”).

be manually inputted for each serial company. Consequently, the ABSCOMP process will be

available in the dashboard, and new serial companies requested to be created via that process will

automatically inherit all dashboard information (e.g., contact information, account

administrators, users, technical administrators, and delegations) associated with the ABS issuing

entity that made the ABSCOMP submission. Changes to the inherited information could be made

after creation of the new serial companies. For example, individuals could be added or removed

on the dashboard by the serial company’s account administrators, while filer information such as

name, address, and State of incorporation could be updated via Company Update submissions

(“COUPDATs”), consistent with current practice.

Another commenter indicated that making the ABSCOMP process available in the

dashboard would be sufficient for ABS entities to manage the creation of new EDGAR accounts

and suggested that similar functionality should be provided for other issuers that have a structure

with multiple related parties, such as co-registrants and beneficial ownership reporting filers, to

allow them to more easily manage EDGAR accounts. 78 We have determined not to extend the

above-described ABSCOMP process to include other entities such as investment companies and

co-registrants, because ABSCOMP is unique in allowing rapid creation of multiple serial

companies via a single transaction, predicated in part upon the serial companies all being largely

identical (e.g., contact information, account administrators, etc.). In contrast, although beneficial

ownership reporting filers and co-registrants may be related parties, each of these filers typically

possesses separate filer-specific information such as name, address, and contact information.

See Toppan Merrill Comment Letter (“The proposed functionality for an ABS account administrator to access

the dashboard for serial companies could be utilized for other issuers who have a related structure with multiple

entities … [i]ncluding … corporate issuers with co-registrants [and] beneficial ownership reporting filers (e.g.,

144, SC 13D, SC 13G, and section 16 filers), and ABS issuers …. If the existing option to create a serial

company by the ‘ABSCOMP’ process is available in EDGAR Next functionality that will be sufficient for ABS

entities to manage creating new CIKs.”).

Furthermore, these filers could have separate reporting obligations (for example, beneficial

ownership reporting filers in the context of different issuers, and co-registrants in the context of

different securities offerings). Thus, in the EDGAR Next framework, each of these filers

presumably would want to authorize her own account administrators, and it would be

inappropriate to automatically assign all such filers the same account administrators. In addition,

the optional APIs being added to EDGAR Next should serve to mitigate any additional burdens

for these filers by allowing the filers to rapidly add account administrators and make other

changes as necessary, as discussed further in section II.E below.

The Proposing Release also requested comment on whether elimination of the ability of

ABS issuers to create new ABS serial companies “on the fly” when filing a 424H submission

would cause any problems, given that the EDGAR Next framework would continue to allow

ABS issuers to request creation of serial companies via ABSCOMP submissions. We received no

comments on this issue. EDGAR data indicates that ABS issuers have not used the “on the fly”

process for several years, and accordingly EDGAR will be updated to remove the ability of ABS

issuers to create new serial companies “on the fly.”

Number of Account Administrators

As contemplated in the proposal, paragraph (d)(2) of Rule 10 as adopted requires filers

who are individuals or single-member companies to authorize and maintain at least one account

administrator; all other filers will be required to authorize and maintain at least two account

administrators. The maximum number of account administrators on the dashboard is 20.

Although individuals and single-member companies are only required to authorize and maintain

at least one account administrator, we encourage them to authorize additional account

administrators in the event the sole account administrator becomes unavailable to manage the

account.

Commenters generally supported the proposed requirement to maintain a minimum of

two account administrators, 79 although various commenters recommended technical changes or

additional clarification. One commenter sought clarification regarding whether, for singlemember companies and individuals, the required account administrator must be the single

member or individual herself. 80 Paragraph (d)(2) of Rule 10 does not require this. Filers will

have the flexibility to authorize individuals at their filing agents or other third parties as account

administrators, so long as they provide notarized powers of attorney authorizing those

individuals. Another commenter requested that an additional warning be provided when the

“single-member company” selection is made to alert the filer that she would be unable to manage

her EDGAR account if the single account administrator is not available. 81 A warning notice will

be added to the online version of Form ID as requested if the “single-member company”

selection is made. Separately, although single-member companies will only be required to have a

single account administrator, we encourage filers to authorize additional account administrators

on the dashboard as necessary (up to a maximum of 20) to ensure that an account administrator

is always available to take necessary actions.

Requiring most filers to authorize at least two account administrators will increase the

ability of filers to manage their EDGAR accounts without interruption. Thus, if an account

administrator unexpectedly resigns or otherwise ceases to be available to manage the filer’s

See, e.g., Toppan Merrill Comment Letter (“Yes, we believe requiring two account administrators is

appropriate.”); Workiva Comment Letter (“We believe at least two account administrators for filing entities

(other than single-member companies) is appropriate.”).

See Workiva Comment Letter (“For individuals and single-member companies, please clarify if the one

minimum administrator must be the individual himself or herself.”).

See Toppan Merrill Comment Letter (“We suggest that additional warnings are provided when the ‘singlemember companies’ selection is made. The warning should alert that access to the filer management website

will be lost if the single administrator is no longer available, which may lead to loss of ability to file on

EDGAR”).

account, the remaining account administrators will continue to manage the account and will be

able to authorize additional account administrators. If the account administrator who seeks to

resign is one of the required two account administrators for an entity filer, then that account

administrator could not be removed from the filer’s EDGAR account unless the filer first added

another account administrator through the dashboard to meet the required minimum of two

account administrators. For example, if there are two account administrators for the account and

one unexpectedly becomes unavailable, the remaining account administrator could add another

account administrator to the account and then remove the unavailable individual. For individual

and single-member company filers, at least one account administrator will always be required

because those filers typically consist of only one individual. A dashboard limit of 20 account

administrators should be sufficient to allow for management of large accounts, while avoiding

the confusion that a larger number of account administrators might cause.

We encourage filers to authorize more than the minimum number of account

administrators, if possible, because if all account administrators for a filer cease to be available

to manage the filer’s account, the filer will be required to submit a new Form ID to authorize

new account administrators. 82

Account Administrator Authorization and Removal of Users, Technical

Administrators, and Other Account Administrators

An account administrator will be able to add or remove an individual as a user, account

administrator, or technical administrator for an EDGAR account through the dashboard, as

discussed in the Proposing Release. An account administrator will “add” the individual on the

In this case, the filer would select the option on Form ID indicating that it had lost electronic access to its

existing CIK account. This option also encompasses other scenarios, such as when a filer loses access due to

failure to satisfy required annual confirmation requirements. See infra note 90.

dashboard and EDGAR will send an invitation to the individual by email and through the

dashboard (if the individual has a role for any filer on EDGAR) indicating that the account

administrator for the filer sought to add her to the filer’s account in a particular role or roles. The

individual must accept the invitation, either through the email or on the dashboard, to accept the

new role(s) and become authorized in those role(s) for the filer. The same process of invitation

both through email and the dashboard applies to all invitations, and the individual receiving the

invitation may accept via the email or the dashboard invitation.

Commenters expressed general support for notifying filers when an account administrator

removes or adds another account administrator. 83 Some commenters, however, expressed the

view that while filer notification would be appropriate, filer consent is not necessary and should

not be required. 84 In response to this point, EDGAR will be enhanced to provide notifications to

all relevant account administrators through the dashboard and by email when individuals are

added or removed from an account, or the roles for those individuals are changed. The discussion

of this matter in the Proposing Release did not indicate that filers would need to consent to these

changes, and EDGAR will not require such consent for the changes to be effective. These

notifications will allow account administrators to monitor relevant activity while minimizing the

delay that might result from approval of each individual action.

Annual Confirmation

See , e.g., XBRL II Comment Letter (“As well as requiring a minimum of two administrators … we do think

notification is appropriate. Alerting other administrators when an administrator is added or leaves will improve

the ability for the network to react to administrator changes.”); DFIN Comment letter (“We also think that a

filer should be notified when additional account administrators are added or removed.”).

See XBRL II Comment Letter (“Addition without consent should be allowed, to manage emergencies that may

arise… We understand that there is still a potential risk with rogue actors at firms, but firms are managing the

risk of rogue actor employees today and should be left to manage that problem in regard to EDGAR Next.”);

Workiva Comment Letter (“We believe the filer’s consent is not necessary as long as the filer has an

administrator that will be notified and can take additional action if needed.”).

Paragraph (d)(4) of Rule 10 as proposed and adopted requires each filer to perform an

annual confirmation on EDGAR that all the filer’s users, account administrators, technical

administrators, and delegated entities are authorized by the filer to act on its behalf, and that all

information related to the filer reflected on the filer’s dashboard is accurate. Account

administrators will act for the filer to carry out this function. Annual confirmation will assist the

filer in tracking those authorized to file on EDGAR and will provide an opportunity for account

administrators to confirm the accuracy of those individuals and delegated entities associated with

the filer and to remove those no longer authorized. In a change from what was contemplated in

the Proposing Release, in response to commenter concerns, we are extending the grace period

before account deactivation for filers that fail to timely perform annual confirmation from two

weeks (as discussed in the Proposing Release) to three months following the annual confirmation

deadline. During the three-month grace period, filers will be able to continue to make

submissions and take actions on EDGAR as usual, while account administrators will receive

notices reminding them to complete annual confirmation by the end of the grace period, as

discussed in more detail below.

To provide flexibility to filers, EDGAR will allow account administrators to select one of

four quarterly dates as the filer’s ongoing confirmation deadline: March 31, June 30, September

30, and December 31 (or the next business day if the date falls upon a weekend or holiday when

EDGAR is not operating). An account administrator need not wait until the deadline to confirm.

An account administrator may choose to perform confirmation at an earlier date within the

quarter when confirmation is due. Further, an account administrator will be able to perform

confirmation on any date in a quarter earlier than the quarter of the current deadline, thereby

changing the quarter when confirmation is due going forward. Confirmation in an earlier quarter

will result in a confirmation deadline one year after the end of the quarter in which the early

confirmation occurred. For example, if a December 31 confirmation deadline were selected by

the account administrator for the initial annual confirmation, but the account administrator

submitted the confirmation for the following year in August, the filer’s annual confirmation

deadline for the next year would be September 30 (or the next business day, if the date fell upon

a weekend or holiday when EDGAR was not operating).

Commenters generally expressed support for account administrator performance of

annual confirmation as contemplated in the Proposing Release. 85 One commenter asserted that

annual confirmations would be overly burdensome, while two other commenters recommended

that confirmations be performed more frequently than annually, such as quarterly or every six

months. 86 We believe that annual confirmation strikes the appropriate balance of periodically

ensuring the accuracy of filers’ information in EDGAR, without unduly burdening filers and

account administrators. To facilitate the confirmation process and remind account administrators

about confirmation deadlines, as discussed in the Proposing Release, EDGAR will provide

periodic notices to account administrators both by email and on the dashboard regarding each

upcoming confirmation deadline, a notice of completion of confirmation, and numerous notices

of failure to timely confirm prior to deactivation of the account. Specifically, prior to the

confirmation deadline, EDGAR will send notices six weeks, three weeks and each of the five

See, e.g., DFIN Comment Letter (“The proposed annual confirmation requirement is sufficient”); Cadwalader

Comment Letter (for annual confirmation for serial trusts, “We believe that such an approach is both

appropriate and efficient.”); Toppan Merrill Comment Letter (asserting that the annual confirmation

requirement would create additional burden for filers but expressing agreement with the requirement as

proposed.).

Compare Block Transfer Comment Letter (“…the benefits of the security measure proposed…would outweigh

the significant burden it would impose on filers’ internal controls.”) with Comment Letter of Uchi (September

13, 2023) (requesting a “3 or 6 month renewal check for the company to ensure all administrative accounts

assigned to the company are still valid as employees incase [sic] of termination while maintaining

administrative access to said company filing permissions.”); Comment Letter of Alexander (September 15,

2023) (same).

business days leading up to the confirmation deadline. If filers fail to perform annual

confirmation on or before the confirmation deadline, EDGAR will send reminders to all account

administrators for the filer each business day after the confirmation deadline until expiration of

the three-month grace period. EDGAR will also offer an optional API to allow filers to

programmatically check filing credentials and upcoming confirmation deadlines.

Several commenters suggested that the Commission allow bulk annual confirmations to

be performed for related EDGAR accounts, such as accounts that share the same administrators,

users, delegations, and corporate and contact information. 87 As discussed above, related EDGAR

accounts (such as co-registrant) may often have different dashboard information, which suggests

that bulk confirmation is not appropriate given the need to separately review and confirm the

accuracy of dashboard information for each filer. 88 We are further concerned that account

administrators might inadvertently perform a bulk confirmation of hundreds of filers without

carefully reviewing each filer’s information. To ensure the accuracy of the filer’s information on

EDGAR, a filer must, through its account administrator, carefully inspect the information on the

filer’s dashboard. As a result, bulk confirmation will not be permitted. Filers may achieve

efficiencies in the confirmation process by leveraging optional APIs that will allow them to

rapidly add and remove individuals, change authorized roles, and perform delegations to ensure

the accuracy of information on the dashboard prior to performing confirmation. For example, in

See Cadwalader Comment Letter (“On an operational level, we do not expect individual serial trusts to have

account administrators, technical administrators, users or delegated entities that are not also performing the

same functions for the depositor, although the depositor may have certain additional account administrators,

technical administrators, users or delegated entities who are not assigned to all of the related serial trusts.

Therefore, depositor-level confirmation of its authorized parties would also encompass all individuals assigned

roles with respect to each individual serial trust.”); Toppan Merrill Comment Letter (responding to a request for

comment regarding whether bulk confirmations should be permitted by stating “Yes, affiliated filers with the

same administrators, users, delegations, and corporate and contact information should be allowed similar

functionality[.]”).

See supra text following note 52.

preparation for confirmation, a filer could view all individuals authorized to act on behalf of the

filer through an API being made available for that purpose. If updates to the roles or

authorization of individuals were needed, the filer could add and remove individuals and change

individuals’ roles through APIs being made available for those purposes.

As noted above, the Proposing Release contemplated a two-week grace period for filers

that failed to perform annual confirmation. Some commenters stated that the annual confirmation

requirement would impose a significant additional burden on filers and recommended that filers

should initially be suspended before they are deactivated, while others requested an extension of

the grace period before deactivating the filer’s access. 89 After considering these comments, we

will expand from two weeks to three months the grace period following a missed confirmation

deadline, during which the filer will be able to continue to make submissions and take actions on

the filer’s account as usual and the filer’s account administrators will receive a final series of

notices reminding them to complete annual confirmation. If no account administrator performs

the annual confirmation by the end of the three-month grace period, EDGAR will deactivate the

filer’s access and the filer will be required to submit a new Form ID application to request access

to file on its account. 90 If Commission staff grant the Form ID, the filer will continue to have the

same account number/CIK previously assigned and its filing history will be maintained. The

See, e.g., Workiva Comment Letter (“We strongly recommend temporary suspension over account

deactivation…. Failure to confirm annually may signal a problem occurred in the notification process rather

than the filer being no longer in control of the account…. Deactivation should only occur after six months of

suspension.”); XBRL II Comment Letter (“The annual confirmation requirement will create a significant

additional burden for filers that use a filing agent's SEC credentials, in particular for those filers who make

sporadic submissions such as Section 16 filers.… We encourage the Commission to consider imposing a

temporary 2-week suspension if the confirmation requirement is not met before deactivating and removing

information from an existing account.”).

In this case, the filer would select the option on Form ID indicating that it had lost electronic access to its

existing CIK account. This option would also encompass other scenarios, such as when all the filer’s account

administrators cease to be available to manage the filer’s account. See supra note 82.

filer’s account administrators listed on Form ID, however, will need to invite through the

dashboard, as if to a new account, additional account administrators, and any technical

administrators and users, and delegate authority to file, if relevant. Although the need to reapply

for access and in particular the need to invite account administrators, users, and technical

administrators anew will impose an additional burden on filers, failure to perform an annual

confirmation, particularly after receipt of multiple notices, could signal that the filer is no longer

managing or controlling the account. Removing individuals from the filer’s account upon

deactivation safeguards information regarding individuals whose information is listed on the

filer’s dashboard. For example, if someone other than the original filer’s account administrators

submitted a Form ID application for access to the account, and the original account

administrators did not respond to Commission staff inquiries regarding the Form ID, the process

outlined above will prevent the new account holder from accessing the names, addresses, and

contact information of the individuals formerly associated with the account. Collectively, this

framework will provide filers that inadvertently miss their annual confirmation deadlines an

additional three months within which to perform their confirmation, during which time they will

receive multiple notices, while maintaining good account hygiene by inactivating defunct

accounts and safeguarding information regarding individuals listed in the dashboard of defunct

filers.

User Groups

Largely as contemplated in the Proposing Release, the dashboard will provide

functionality to allow an account administrator to group subsets of the filer’s users into user

groups. The user group function will assist delegated entities to authorize certain of their users to

make submissions on behalf of specific filers, as explained below. By employing user groups,

the delegated administrator can add or remove the ability to make submissions for a certain filer

to all users in the group at once and can give specific groups of users the ability to make

submissions for certain filers, leading to efficiencies of time in managing users.

One commenter stated that EDGAR should allow multiple users to be added to a user

group simultaneously to ensure that user groups can be built quickly and efficiently. 91 As

requested by the commenter, the dashboard will be updated to permit filers to add multiple users

to a user group simultaneously. In addition, optional APIs will be provided so that filers can view

individuals in any role for a CIK, add individuals, remove individuals, and change roles for

individuals; collectively, this should facilitate the ability of filers to manage user groups.

One commenter stated that user group functionality would be improved by allowing

wildcard searches to include first and last names. 92 Accordingly, the dashboard will be enhanced

to enable first and last name wildcard searches of individuals.

Users

Largely as contemplated in the Proposing Release, account administrators will be able to

authorize individuals with individual account credentials as users to make submissions on

EDGAR on behalf of the filer. 93 Account administrators and Commission staff will be able to

determine which users made which submissions; however, this information will not be made

public on EDGAR. The dashboard will allow users to generate, view, and copy user API tokens,

if using optional APIs that require presentation of a user API token; view relevant notifications

(which will also be provided to users by email); and view basic information about the filer’s

See Toppan Merrill Comment Letter (“The system should allow for multiple users to be uploaded at the same

time. This will ensure that users groups can be built quickly and efficiently.”)

See Toppan Merrill Comment Letter (“User group functionality would be improved by allowing for wildcard

searches to include first and last names. Currently, the search disregards any name after the space between the

first and last name.”).

Commenters were generally supportive of the user role. See comments by Toppan Merrill, DFIN, SIFMA, and

XBRL II.

account, including the filer’s name, CIK, CCC, corporate and contact information, as well as

contact information for account administrators. Users will not, however, be able to add or

remove individuals from the dashboard other than themselves. Users also will not be able to

generate a new CCC. Separately, users will be able to make COUPDAT submissions to update

filer information such as name, address, and State of incorporation, as filers currently do.

As part of the login and authentication process for the EDGAR filing websites, a user will

be able to select the EDGAR account number (CIK) of the entity for which submissions are

being made (“login CIK”). That CIK will be reflected in the first part of the unique identifier

associated with each submission (the “accession number”). 94 Users will be able to change their

Becoming Authorized as a User

An account administrator can “add” an individual through a dashboard function that will

generate an invitation to the individual to be a user for the filer’s account. Prospective users will

receive email invitations from EDGAR and, if the prospective user has a role for any EDGAR

account, a notification of the invitation will appear on the prospective user’s dashboard. The

individual must accept the invitation, through either the email or dashboard invitation, to become

a user. As noted, the same process of invitation and acceptance both through email and the

dashboard applies to all invitations.

One commenter suggested the addition of functionality to allow filers to directly

authorize their financial advisers (i.e., registered representatives of broker-dealers) to act as

An accession number is a unique identifier assigned automatically to EDGAR submissions for tracking and

reference purposes. The first 10 digits are intended to represent the CIK of the entity making the submission,

which may be an entity with reporting obligations or a third party (such as a filing agent).

users. 95 Although there are additional requirements related to the authorization of third parties as

account administrators on Form ID, those requirements will not apply to users. 96 Account

administrators will be able to authorize any individual with Login.gov credentials as a user,

therefore, for example, account administrators will be able to authorize financial advisers as

users to make submissions on the filer’s behalf.

Number of Users

There will be no minimum number of users because account administrators will be able

to make submissions on behalf of the filer. We are setting the maximum number of users per filer

on the dashboard at 500, as proposed.

The Proposing Release discussed a maximum of 500 users per filer, based in part on

feedback received from commenters on the 2021 Request for Comment. One commenter that

responded to the 2021 Request for Comment conducted a filer survey that indicated that 4% of

the filers it surveyed would be interested in authorizing 20 or more users, up to a maximum of

150 users per filer. 97 In response to the 500-user limit contemplated in the Proposing Release,

one commenter agreed that a limit of 500 users would be sufficient. 98 In contrast, one commenter

suggested that the limit should be increased but did not provide a specific number, while another

suggested that the limit should be tripled to 1500 users per filer on the grounds that doing so

See SIFMA Comment Letter (“We recommend that the SEC provide functionality that would allow retail

clients to directly authorize their financial advisers (i.e., registered representatives of the broker-dealer) to act as

a ‘user’ for the sole purpose of filing the Form 144s.”).

See supra note 75 and accompanying and following text (discussing notarization requirements for individuals

who are not employed at the filer or an affiliate of the filer).

See Workiva Comment Letter (November 30, 2021) (“Based on the survey we conducted, about 1% of

respondents indicated their plan to set up as high as 10-30 account administrators, while 4% indicated 20-150

users.”).

See XBRL II Comment Letter (“We believe that the limit of 500 authorized users per filer is sufficient.”).

would “accommodate larger entities.” 99 We believe that a maximum of 500 users per filer on the

dashboard should be sufficient to accommodate sophisticated filers making a large number of

varied filings. 100 Five hundred users is more than three times the high-end number cited in the

commenter survey conducted in connection with the 2021 Request for Comment, and was

deemed to be sufficient by an industry membership organization. 101 Moreover, filers will be able

to more efficiently and rapidly make submissions through optional APIs, mitigating the need to

have more than 500 users per filer. 102

Technical Administrators

Paragraph (d)(3) of Rule 10 as adopted and largely as proposed requires filers that opt to

connect to the EDGAR APIs to authorize, through their account administrators, at least two

technical administrators to manage the technical aspects of a filer’s connection to the APIs,

unless the filer arranges to use its delegated entity’s API connections and the delegated entity is

in compliance with the requirement to authorize at least two technical administrators. We

anticipate that the role of technical administrator could be filled by someone with a primarily

administrative background because the requirements of the role are to generate and provide filer

API tokens and to manage the filer’s connections to APIs. We are not requiring that the technical

administrator role be filled by software developers or other technically expert staff; rather, the

technical administrator should have a basic understanding of API processes and be available to

communicate with Commission staff and the filer’s developers or other technical experts

See Toppan Merrill Comment Letter (“Additionally, EDGAR Next should allow an organization to add more

than 500 authorized users, as needed.”); DFIN Comment Letter (“To accommodate larger entities, we suggest

an increase to the authorized user limit from 500 to 1,500.”).

100

In the future, if it seems that there is a need for additional users to be added, the limit on the number of users

may be reevaluated.

101

See supra notes 97-98.

102

See generally section II.E.

expeditiously, in addition to generating and managing the filer API tokens.

Commenters generally indicated support for adding a technical administrator role as

beneficial to help manage a filer’s connection to APIs. 103 One commenter suggested that it saw

“material problems” with the role of technical administrator but did not enumerate what those

problems were. 104 The commenter suggested Congressional consideration regarding creation of a

“unified, government-wide platform that ensures robust authentication and streamlined

management of API interaction for various Federal services, including EDGAR.” 105 We note that

such an undertaking is outside the scope of this rulemaking.

We are adopting paragraph (d)(3) of Rule 10 with a modification to permit a filer to use

the API connections and filer API tokens of its delegated entity (as long as that delegated entity

is in compliance with the requirement to authorize at least two technical administrators); and a

filer that does so will not be required to authorize at least two technical administrators and

generate a filer API token itself. 106 The relevant individual at the filer interacting with the API,

however, must present a valid user API token to the API if the relevant API requires presentation

of a user API token, to allow identification of the individual taking action on EDGAR. To

accommodate this change and to better reflect the technical connection of filers to the optional

103

See Toppan Merrill Comment Letter (“[We] believe a technical administrator role is beneficial to help manage a

filer’s use of APIs.”); Workiva Comment Letter (“[W]e agree with the option to have a technical administrator

role for those who wish to utilize IT support to manage API tokens …. .”).

104

See Block Transfer Comment Letter (“We respectfully submit . . . an innovative approach . . . because(i) the

role of technical administrator has material problems and (ii) other Federal agencies require machine-tomachine data submission from the private sector, most generally from financial services firms.”).

105

See Block Transfer Comment Letter (“We respectfully submit ... an innovative approach … [that] envisages a

unified, government-wide platform that ensures robust authentication and streamlined management of API

interactions for various Federal services, including EDGAR…. For these reasons and more, we respectfully

submit … that a brief Congressional consideration is in order to ponder the creation of a report as to the

strengths and weaknesses a unified Login.gov machine-to-machine authentication system may bestow upon on

our cybersecurity interests both domestically and abroad….”).

106

See generally section II.C.6.

APIs, paragraph (d)(3) of Rule 10 will refer to filers that “connect to” APIs rather than filers that

“use” APIs. This option is being offered for filers who would like their account administrators

and users to be able to interact with the APIs directly, but who do not wish to undertake the

expense to connect to the APIs and authorize technical administrators. 107

Authority of Technical Administrators

A technical administrator will issue and deactivate filer API tokens required to connect to

the optional APIs. Technical administrators will also serve as points of contact for questions

from Commission staff regarding the filer’s connections to the APIs and will receive relevant

notifications on the dashboard and by email, such as reminders regarding upcoming expiration

dates for filer API tokens.

Two commenters suggested that the technical administrator and account administrator

roles could be filled by the same person. 108 As discussed in the Proposing Release, a filer will

have the option of designating the same individual to serve as both its technical administrator

and account administrator, but the filer may also choose to authorize different individuals to

serve in these roles provided those individuals possess individual account credentials obtained in

the manner specified in the EDGAR Filer Manual.

b. Becoming a Technical Administrator

To authorize an individual as a technical administrator, an account administrator will add

107

108

As set forth in paragraph (d)(3) of Rule 10, filers who do not want their account administrators or users to

generate user API tokens could alternatively allow their delegated entities to make submissions on their behalf

through APIs, and individuals at the delegated entities would present their own user API tokens to make

submissions.

See Workiva Comment Letter (“[W]e believe that the administrator and the technical administrator can be the

same person and would likely be most of the time.”); XBRL II Comment Letter (“We do not understand the

difference between a technical administrator and an account administrator. The addition of a technical

administrator role may further complicate the process. It could be useful if this role were optional and could be

combined into the account administrator if the company chose to, for example if the account administrator

could generate the filer token.”).

the individual in that role on the dashboard, triggering an invitation to the individual. The

prospective technical administrator will receive the invitation by email, and, if the individual

already has a role for any EDGAR account, on the dashboard. The prospective technical

administrator must accept either the dashboard or the email invitation to become authorized as a

technical administrator.

Number of Technical Administrators

Paragraph (d)(3) of Rule 10 as proposed and adopted will require filers that choose to

connect to an API to authorize, through its account administrators, at least two technical

administrators. In a change to what was proposed, however, paragraph (d)(3) of Rule 10 will not

impose a requirement to authorize at least two technical administrators if the filer arranges to use

its delegated entity’s API connections and filer API tokens and the delegated entity is in

compliance with the requirement to authorize at least two technical administrators. Further, while

the Proposing Release indicated that filers would be able to authorize a maximum of 10 technical

administrators, in response to requests from commenters, the maximum number of technical

administrators will be increased to 20.

One commenter generally supported the designation of at least two technical

administrators for filers connecting to APIs. 109 Two commenters generally supported the

minimum of two technical administrators for companies, but asserted that only one technical

administrator should be required for individuals and single-member companies, in order to

parallel the minimum number of account administrators needed for those entities. 110 One

109

See Toppan Merrill Comment Letter (“[A] minimum of two technical administrators should be required to

manage a filer’s APIs….”)

110

See Workiva Comment Letter (“[I]ndividuals or single-member firms should have the option to handle

everything directly without involving an additional party. The requirement of at least two technical

commenter stated that “requiring two technical admins presents many material legal, efficiency

and operational risks,” but did not specify the anticipated risks or how many technical

administrators would be sufficient to address those anticipated risks. 111 We believe that requiring

a minimum of two technical administrators for filers that choose to connect to optional APIs will

increase the likelihood that Commission staff can contact one of the filer’s technical

administrators and reduce the chance of disruption of API connections. We believe that larger

filers and filing agents using APIs should have sufficient staff to authorize two technical

administrators. In addition, if individuals and single-member companies choose to connect to

APIs, we anticipate that they will either employ filing agents, use their delegated entities’ API

connections, or otherwise have available staff to comply with the paragraph (d)(3) requirement

of Rule 10 to authorize at least two technical administrators.

As noted, as a departure from what was contemplated in the Proposing Release, a filer

may use its delegated entity’s filer API tokens and API connections if the delegated entity is in

compliance with the paragraph (d)(3) requirement of Rule 10 to authorize two technical

administrators. The filer must delegate authority to file through the dashboard and coordinate

with the relevant delegated entity to use the delegated entity’s API connections and filer API

tokens, and the individual at the filer making the submission must present her own user API

token to the API, if the relevant API requires presentation of a user API token. This change will

obviate the need for filers to create their own API connections and authorize their own technical

administrators should they want their account administrators and users to make submissions and

administrators would impose the need to involve a second person purely for the purpose of using software to

file.”); DFIN Comment Letter (“We think the technical administrator minimum requirements should parallel the

account administrator minimum requirements.”).

111

See Block Transfer Comment Letter.

interact with EDGAR through the optional APIs, and further responds to suggestions raised by a

commenter. 112 These filers may leverage the API connections and filer API tokens of filers’

delegated entities, and the individual at the filer need only supply her user API token to the API,

if the relevant API requires presentation of a user API token. 113

Because paragraph (d)(3) of Rule 10 as amended will require a filer to authorize, through

its account administrators, at least two technical administrators to connect to the optional APIs,

the dashboard will not allow a technical administrator to be removed from a filer’s account when

only two technical administrators are authorized on the account. An account administrator will

first need to add another technical administrator on the dashboard.

In a change from the contemplated maximum of 10 technical administrators per filer,

there will be a maximum of 20 technical administrators per filer. Several commenters suggested

that this limit be increased to parallel the limit for the maximum number of account

administrators. 114 Having the same maximum limit for account administrators and technical

administrators will facilitate the ability of filers to authorize the same individuals in those roles.

Delegated Entities

112

See Workiva Comment Letter (“One solution would be to allow the registrant’s authorized user to use their

token with the delegated filing software’s filer token.”).

113

Alternatively, if filers wish to make submissions through APIs but do not wish their staff to be required to

generate user API tokens, filers could arrange for their delegated entities to make submissions through APIs on

their behalf. In this case, delegated entities would create the API connections, maintain at least two technical

administrators, and generate filer API tokens, and the relevant delegated administrators and delegated users for

these filers (at the delegated entities) would present their own user API tokens, if the APIs require presentation

of a user API token. Of course, filers who wish to make submissions through APIs may also determine to create

their own API connections to EDGAR, authorize at least two technical administrators, present their own filer

API tokens, and have their account administrators and users generate and present their user API tokens, if the

APIs require presentation of a user API token.

114

See Toppan Merrill Comment Letter (“A minimum of two technical administrators should be required to

manage a filer’s APIs, as proposed. We would prefer that the maximum number of technical administrators

match the number of account administrators (20). This ensures that larger entities will not encounter any

limitations.”); Workiva Comment Letter (“[T]he technical administrator and administrators can often be the

same person. Thus, we believe the limits for administrators and technical administrators can be the same.”).

Largely as contemplated in the Proposing Release, a filer will be able to delegate

authority to file on its behalf to any other EDGAR account, such as a filing agent, which will

become a delegated entity for the filer. As discussed above, the CCC will appear on the

dashboard of individuals authorized to make submissions for the filer, including delegated

administrators and delegated users. 115

Delegating Authority to File

A filer’s account administrator may delegate authority to file to another EDGAR account

through a function on the dashboard, as discussed in the Proposing Release. 116 After the account

administrator selects the EDGAR account to which the filer seeks to delegate authority to file,

EDGAR will send both email and dashboard invitations to the account administrators for that

account. One account administrator for the prospective delegated entity must accept either the

email or the dashboard invitation for the delegation to become effective. If the filer’s account

administrators wish to terminate the delegation, they can do so on the dashboard. Removal of

delegation will not require acceptance by the delegated entity. An account administrator will be

able to delegate authority to file to an unlimited number of EDGAR accounts, allowing filers to

delegate to multiple filing agents, for example, should they so choose. Similarly, an EDGAR

account can accept an unlimited number of delegations from filers.

In response to commenter suggestions, the dashboard will be enhanced to: (1) provide

bulk delegation functionality to allow filers to delegate to multiple EDGAR accounts more

easily; (2) enable prospective delegated entities to send delegation requests to filers; and (3)

allow EDGAR accounts to automatically accept delegations and become delegated entities if

115

See supra note 60.

116

An optional delegation API will be offered in addition to the delegation capabilities of the dashboard.

they choose.

Commenters generally supported the ability to delegate, 117 although various commenters

raised concerns about certain situations or recommended certain changes as discussed further

herein. Multiple commenters requested that bulk delegation be permitted, so that filers could

delegate to multiple EDGAR accounts simultaneously via a single invitation. 118 After

considering these comments, bulk delegation functionality will be added to the dashboard to

allow filers to delegate to multiple EDGAR accounts more easily. For recordkeeping and

administrative purposes, delegated administrators will receive separate invitations for each

delegation, but they will be able to accept multiple invitations in bulk, which should address

commenters’ concerns about minimizing burdens on delegated administrators who receive bulk

delegations.

Multiple commenters also asked that prospective delegated entities be able to request

delegation. 119 This process would enable filing agents, for example, to assist their client filers in

delegating to the correct EDGAR accounts. In response to these comments, the dashboard will be

enhanced to enable prospective delegated entities to send delegation requests to filers. The

117

See, e.g., DFIN Comment Letter (“Filers should be able to delegate to anyone they want to file on their

behalf.”); Toppan Merrill Comment Letter (“We agree that an account administrator should be able to delegate

filing authority to any EDGAR filer.”)

118

See, e.g., Comment Letter of Wanda Welch (November 13, 2023) (“Welch Comment Letter”) (“We would like

the ability to delegate to more than one CIK at a time and receipt of one email invite.”); XBRL II Comment

Letter (“[We] recommend that a bulk delegation function be made available to assist filers that have multiple

CIKs, and that this capability be allowed using a single invitation request (rather than multiple invitations for

multiple CIKs.”); DFIN Comment Letter (“We think that a bulk delegation function would be beneficial for

filers that have multiple CIKs. Also, the bulk delegation should produce one invitation request. The recipient

would then only need to accept one invitation as opposed to several invitations.”); ICI Comment Letter (“There

should be consideration for bulk delegation for a group of CIKs.”).

119

See, e.g., SIFMA Comment Letter (“We recommend that the system permit filing agents … to affirmatively

request delegated authority (on an individual or bulk basis) from a given filer or filers.”); Workiva Comment

Letter (“[We] recommend adding the capability for an entity to request delegation.”); XBRL II Comment Letter

(“Vendors should be able to proactively request delegation from the registrant and receive confirmation [of

delegation] on the site.”).

delegation requests will prompt filers’ account administrators to send delegation invitations to

the delegated entities, and filers’ account administrators can determine whether they wish to send

such delegation invitations. If the filers’ account administrators send the delegation invitations,

the delegated entities’ account administrators must accept the invitations for the delegation to be

effective.

Separately, several commenters requested that prospective delegated entities be able to

automatically accept delegation invitations to lessen the burden on delegated entities’ account

administrators to manually accept each invitation. 120 The dashboard will be enhanced

accordingly to allow prospective delegated entities to opt to automatically accept delegation

invitations.

One commenter was critical of the proposal’s delegation of authority capabilities,

warning that broad permissions granted to delegated entities to make submissions for the filer

represent a significant risk regarding the accuracy and authenticity of filings. 121 We do not

believe a delegated entity with permissions to make submissions for the filer will pose a

significant risk because such risk is mitigated through the authorization requirements and

verification. For example, delegated entities must be authorized and confirmed by a filer’s

account administrator on the dashboard, ensuring that only authorized and trusted entities are

able to make submissions for the filer. Additionally, a delegated entity must have an EDGAR

account and will be subject to the same requirements applicable to all filers. For the delegation to

become effective, an account administrator of the delegated entity must accept the invitation,

120

See Workiva Comment Letter (“[We] also suggest adding an option to allow filing agent-type CIKs to autoaccept delegations.”); XBRL II Comment Letter (asserting that filing agents/vendors should be able to request

delegation, which could “be automatically approved by the registrant.”).

121

See Block Transfer Comment Letter (“There is real risk that delegates, armed with expansive filing capabilities,

might submit false or misleading information, either inadvertently or maliciously.”).

which means the account administrator at the delegated entity must first log into EDGAR using

her individual account credentials and perform multifactor authentication.

Commenters also raised concerns regarding burdens potentially associated with

delegating authority to make submissions to co-registrants and asked for clarity regarding how

such delegations would work. 122 Commenters further urged the Commission not to require that

co-registrants be added to an EDGAR account as a user, account administrator, delegated user,

or delegated administrator to make submissions, so long as the individual making the submission

had the correct role-based permissions for the primary registrant and had provided the correct

CCCs for the co-registrants, as currently required. 123 We acknowledge that requiring separate

dashboard permissions for each co-registrant to make submissions could potentially be

confusing. We also recognize concerns that commenters separately raised about the need for

additional optional APIs, including APIs to verify filing credentials, view filer account

information, and replicate dashboard functionality that would assist filers if co-registrants were

required to have dashboard permissions to make submissions. 124 EDGAR will not require rolebased permissions for co-registrants at this time, and the addition of co-registrants to a filing will

continue to be performed the same way it is currently performed (i.e., simply by listing the CIK

and CCC of each co-registrant).

122

See, e.g., Welch Comment Letter (“Does the Subject Company and the Co-registrants need to be delegated?”);

DFIN Comment Letter (“[F]ilers would face difficulties in delegating co-registrants. Especially when it relates

to merger acquisitions that may include hundreds of co-registrants.”).

123

See, e.g., Workiva Comment Letter (“Only the primary registrant’s set of valid credentials should be required to

file for all co-registrants, and delegation or a function to designate as ‘co-registrant’ is not necessary. Adding

designation requirements significantly increases the risk for the overall filing submission.”); XBRL II Comment

Letter (“We encourage the Commission to continue the existing beta implementation [for co-registrants], which

only forces the Filer and User Token requirements for the primary registrant, into the final rule/implementation

phase.”).

124

See infra section II.E.

Separation of Authority of Filer and Delegated Entity

A filer’s account administrator will not be able to access its delegated entity’s dashboard

or account or add or remove delegated users at the delegated entity, as discussed in the proposal.

While delegated administrators and delegated users will be able to make EDGAR submissions

and access the “Retrieve/Edit Data” section of the EDGAR Filing website on the filer’s

behalf, 125 delegated administrators and delegated users similarly will not be able to access the

filer’s dashboard 126 or take dashboard actions on behalf of the filer.

Separately, as one commenter requested, the dashboard will be modified to allow

delegated administrators and delegated users to make both COUPDAT and series and class

update (“SCUPDAT”) submissions. The Proposing Release contemplated that delegated

administrators and delegated users would be able to submit SCUPDAT submissions on the filer’s

behalf to update series and class information (such as a new share class) but would not be able to

make COUPDAT submissions to update the filer’s company information (such as a new business

address). One commenter asserted that delegated administrators and delegated users should be

able to submit both COUPDATs and SCUPDATs on behalf of the filer. 127 Because allowing

delegated administrators and delegated users to make both COUPDAT and SCUPDAT

125

The “Retrieve/Edit Data” section of the EDGAR Filing website currently allows filers to perform certain

administrative actions. Among other things, filers may view/edit their account information (such as the filer’s

name, contact information, and corporate information like State of incorporation and fiscal year-end), view the

filer’s current account balances and request the return of unused funds, and change the filer’s password or CCC.

As part of the transition to EDGAR Next, some of this functionality will be shifted to the dashboard, such as the

filer’s EDGAR POC. See infra note [125] and accompanying text.

126

As discussed further below in section II.C, the dashboard will generally be used to manage a filer’s EDGAR

account, including management of individuals authorized to act as account administrators, users, and technical

administrators; management of entities authorized to act as delegated entities; and management of filer and user

API tokens. Delegated entities will not need to access the filer’s dashboard in order to make filings on the filer’s

behalf, since filings will be made directly on the EDGAR filing websites or through the optional APIs, as

opposed to through the filer’s dashboard.

127

See DFIN Comment Letter (“Delegated administrators and delegated users should have the ability to submit

COUPDAT (company update submissions) and SCUPDAT (series & class updates).”)

submissions provides consistency and reduces burdens associated with these updates, to the

extent that such updates could then be delegated by the filer, this capability will be implemented

in EDGAR. The filer’s account administrators would receive notice of COUPDAT and

SCUPDAT submissions on the dashboard and could take appropriate action should any

unauthorized activity occur.

Delegated entities will not be able to further delegate authority to file to other entities on

behalf of filers that delegate authority to them. 128

Delegated Entities

Because a delegated entity must have an EDGAR account, it must comply with the same

requirements applicable to all filers. A delegated entity will therefore maintain its own EDGAR

account with its own account administrators, users, and technical administrators. A delegated

entity can be any EDGAR account, including but not limited to filing agents, 129 issuers making

submissions on behalf of individuals filing pursuant to section 16 of the Exchange Act, and

parent companies of large groups of related filers. On the dashboard, a delegated entity will be

able to receive delegated authority to file for an unlimited number of filers.

Several commenters provided comments on delegation specifically related to individuals

with filing obligations pursuant to section 16 of the Exchange Act. Commenters indicated that

the delegation framework contemplated by the Proposing Release would help section 16 filers

128

For example, Filer A could delegate authority to file on its behalf to Filer B. Separately, Filer B could delegate

authority to file on its behalf to Filer C. In this scenario, however, Filer B could not delegate to Filer C the

authority to file on behalf of Filer A, and Filer C could not file on behalf of Filer A.

129

We are adopting amendments to Rule 11 of Regulation S-T to define a “filing agent” as any person or entity

engaged in the business of making submissions on EDGAR on behalf of filers. This definition includes law

firms, financial services companies, broker dealers when making submissions on behalf of individuals filing

pursuant to section 16 of the Exchange Act, and other entities engaged in the business of submitting EDGAR

filings on behalf of their clients. See the discussion of amendments to Rule 11 in section II.F.2.

comply with their filing obligations. 130 Individuals with section 16 filing obligations will be able

to delegate authority to make submissions to filing agents or any other representative with an

EDGAR account on the dashboard. This process will allow those individuals to obtain assistance

with their filings, while permitting each filing to be associated with a specific individual at the

delegated entity. One commenter asserted that section 16 filers would face compliance burdens,

however, that would not be adequately addressed by the proposal. 131 The commenter stated that

section 16 filers can sit on the boards of multiple companies and concluded that section 16 filers

need an easier method to delegate permissions. As discussed above and as separately requested

by commenters, the dashboard will include bulk delegation functionality, which should assist

filers with multiple filing agents or other representatives with EDGAR accounts, including

section 16 filers delegating authority to make submissions to related issuers. 132 The staff will

provide detailed information about bulk delegation and other account management topics to

section 16 filers to prevent confusion. Moreover, section 16 filers may choose to execute

notarized powers of attorney to authorize relevant individuals at their filing agents, related

issuers, or other representative entities as account administrators, thereby avoiding the need to

obtain individual account credentials, log into the dashboard, make filings or delegate authority

130

See XBRL II Comment Letter (“Yes, the ability to delegate authority would help infrequent filers such as

Section 16 filers.”); Workiva Comment Letter (responding to the Commission’s request for comment regarding

section 16 filers by stating: “We believe the proposed framework is adequate to support filing

responsibilities.”).

131

See XBRL II Comment Letter (“[W]e do not believe the rule proposal adequately addresses the needs of

Section 16 filers and single individual filers [who] will perform their own code management. For these filers,

the rule does not specifically address how they can manage this. Many sit on boards of multiple companies,

some as many as 20, and will need to set up or designate each individual as an account administrator. The

Commission needs to address how there can be an easier method to delegate permission for someone to file on

their behalf.”).

132

See supra note 107 and accompanying and following text; see also Toppan Merrill Comment Letter (“Allow

bulk delegation for a group of CIKs. This would be useful for an Administrator of an Issuer and all of their

Section 16 filer CIKs to delegate to Filing Agents as well as affiliated CIKs.”).

on the dashboard.

If a filer authorizes a delegated entity to file on its behalf, one of the delegated entity’s

account administrators must accept either the dashboard or the email invitation for the delegation

to be effective; further, upon acceptance, all the delegated entity’s account administrators will

automatically become delegated administrators for the filer. All delegated administrators for the

filer will have co-equal authority with regard to that filer. If the delegated entity adds or removes

one of the account administrators for its own EDGAR account, then that individual will also be

added or removed as a delegated administrator for the filer. These relationships are illustrated in

diagram 3 below.

Delegated Users

As described in the Proposing Release, if a delegated entity accepts a delegation from a

filer, the delegated administrators can authorize specific users at the delegated entity to become

delegated users with respect to that filer. As discussed below, delegated administrators will be

able to authorize delegated users in accordance with the process outlined in the Proposing

Release. In addition to what was discussed in the Proposing Release and taking account of a

commenter’s suggestion, the dashboard will be updated to generally enable bulk actions in

various contexts, including delegation.

Delegated users will not count as part of the 500-user limit on the dashboard for the

delegating filer. If delegated administrators want all their users to become delegated users with

respect to a filer, a delegated administrator can check a box on the dashboard to automatically

authorize all users at the delegated entity as delegated users for the filer. Alternately, delegated

administrators will be able to authorize a subset of the delegated entity’s users as delegated

users; authorize all of the delegated entity’s users as delegated users for the filer; or not authorize

any delegated users (because the delegated administrators will be able to file on behalf of the

filer). 133 After the delegated user accepts the initial invitation from the delegated administrator,

the user will receive notifications regarding further changes to its role (including changes to

filers for which it will be a delegated user, and changes to the user groups it will be affiliated

with), but the user will not need to accept those notifications or take any further action for the

changes to be effective.

One commenter stated that delegated administrators should be able to remove a delegated

user from all delegations via a single bulk action without having to manually edit each

delegation. 134 The commenter further asserted that delegated users should be able to remove

themselves from all delegations without editing each delegation. 135 In these circumstances, we

believe that it is more likely that a delegated administrator would remove a delegated user, or the

delegated user would remove herself, as a user for the delegated filer, and thus the dashboard

133

For this reason, delegated administrators could not be authorized as delegated users regarding the delegating

filer, because doing so would be redundant.

134

See Workiva Comment Letter (“[D]elegated admins should be able to remove a delegated user from all

delegations without having to edit each delegation one by one as the person may need to remain on the

Dashboard for a role other than the delegated role.”).

135

See Workiva Comment Letter (“[D]elegated users should have the ability to remove themselves from all

delegations without editing one by one.”).

will not specifically provide these requested features. The dashboard will be enhanced, however,

to generally enable bulk actions in various contexts, including with respect to delegation. 136 In

addition, optional APIs will be offered to allow filers to add and remove individuals’

authorizations rapidly and easily. These accommodations should largely address commenters’

concerns; in addition, further technical enhancements to the dashboard will continue to be

considered.

Delegated users will be able to submit filings on behalf of the filer on the EDGAR filing

websites or through the optional submission API, as discussed below.

User Group Functionality at Delegated Entities

Delegated entities, through their delegated administrators, will be able to employ user

groups to assign certain users to different filers for which they possess delegated authority to file,

as described in the Proposing Release. An example is provided in diagram 4 below.

136

See text following note 118 (discussing the dashboard’s bulk delegation functionality).

•

In diagram 4, the account administrators for Filer A and Filer B delegated to Filer C. As a

result, Filer C’s account administrators became delegated administrators for Filers A and

B. In this example, Filer C might be a filing agent to which Filer A or Filer B gave

authority to make filings on its behalf, and Filer A and Filer B might be public companies

or investment companies.

•

A delegated administrator at Filer C created User Group 1 containing Filer C’s Users 1,

2, and 3. The delegated administrator assigned authority to file for Filer A to User Group

1. Users 1, 2, and 3 are thus delegated users for Filer A because they are members of

User Group 1. If additional users from Filer C were added to User Group 1, those

additional users would also become delegated users for Filer A.

•

The delegated administrator at Filer C also created User Group 2 containing Filer C’s

User 3. The delegated administrator assigned authority to file for Filer B to User Group 2.

User 3 is a delegated user for Filer B.

•

By employing the user group function, the delegated administrator at Filer C restricted

delegated filing permissions for Filer A to Filer C Users 1, 2, and 3 only (via User Group

1) and delegated filing permissions for Filer B to Filer C User 3 only (via User Group 2).

Filer C User 4 has not been authorized as a delegated user for any filers.

•

In diagram 4, each user group has only been assigned authority to file for a single filer,

but user groups could be assigned authority to file for multiple filers.

Delegated administrators will also be able to authorize a default user group of individuals

who will be automatically assigned as delegated users for all future delegations. The ability to

have a default user group will provide an efficient way for delegated administrators to authorize

groups of their users as delegated users for any filer.

Users will receive notifications when added to or removed from a user group, and when

the user group to which they belonged becomes authorized to make submissions for a filer, or

when that authorization is removed. As noted, users will not need to accept or otherwise take any

action on these notifications.

As discussed above, in response to comments received, the dashboard will be enhanced

to allow wildcard searches including first and last names, which should make it easier for filers

to construct user groups and to generally manage individuals on the dashboard. 137

Technical Administrators at Delegated Entities

If the delegated entity chooses to connect to APIs, the delegated entity will be required

to authorize its own technical administrators, as discussed in the Proposing Release, and required

by paragraph (d)(3) of Rule 10 as adopted. The delegated entity’s technical administrators will

be responsible for managing the API connections and the filer API tokens for the delegated

entity. The delegated entity may make submissions for any filers that delegate authority to it

using the delegated entity’s API connections and filer API tokens, and the individual at the

delegated entity making submissions for the filer would present his user API token generated on

the dashboard, if the relevant API requires presentation of a user API token.

In addition, as discussed above, in a change from what was contemplated in the

Proposing Release, paragraph (d)(3) of Rule 10 as adopted now specifies that a filer may use its

delegated entity’s API connections and filer API tokens so long as the delegated entity complies

with the requirement to maintain at least two technical administrators. The delegated entity’s

technical administrators may share the delegated entity’s filer API tokens with its filers, as

discussed further below. The delegated entity’s technical administrators will not need to generate

137

See supra note 92 and accompanying and following text.

different filer API tokens for different delegating filers that use the delegated entity’s API

connections. The individual at the filer using the delegated entity’s API connections and filer

API tokens must present her own user API token to the APIs, if the particular APIs require

presentation of a user API token.

Hours of Operation of the Dashboard

As contemplated in the Proposing Release, the dashboard will be available during

EDGAR operating hours, 6 a.m. to 10 p.m. Eastern Time each day except Saturdays, Sundays,

and Federal holidays. Optional APIs that provide much of the same functionality as the

dashboard will also be available during those hours because the APIs rely on dashboard

availability.

Several commenters requested increased dashboard operating hours, including requests

that the dashboard be available during weekends and/or 24 hours a day. 138 While we

acknowledge commenters’ concerns, the dashboard will be available during current EDGAR

operating hours, the time period during which EDGAR filings can be submitted, 139 which is 16

hours per business day. We believe this availability should generally be sufficient for filers’

needs, as it has been for EDGAR filing availability to date. Further, optional APIs providing

much of the functionality on the dashboard will allow filers to rapidly make submissions and

otherwise transmit and receive information from EDGAR, significantly increasing filers’

efficiency during EDGAR operating hours. In addition, filers that build internal systems to

138

See, e.g., Toppan Merrill Comment Letter (“It would be beneficial to allow the dashboard to be open 24 hours a

day, Monday through Friday.”); Block Transfer Comment Letter (“We respectfully believe the Commission

should not limit EDGAR Next operations to the D.C. workweek…. [W]e believe a 24/7 EDGAR would

revolutionize international capital markets by providing a standard for all issuers.”).

139

Regulation S-T provides that filings “may be submitted to the Commission each day, except Saturdays,

Sundays, and Federal holidays, from 6 a.m. to 10 p.m., Eastern Standard Time or Eastern Daylight Saving

Time, whichever is currently in effect.” 17 CFR 232.12(c).

connect to the optional APIs could potentially include features such as scheduling filings for

submission, as filers currently do, reducing the need for the dashboard to be offered 24 hours a

day or during weekends and holidays.

Optional Application Programming Interfaces

Commenters broadly supported the addition of optional APIs to EDGAR, including those

listed in the Proposing Release. 140 EDGAR will therefore offer the optional APIs detailed below

to provide filers with secure, efficient and automated methods of interacting with EDGAR.

These optional APIs will be available to enrolled filers upon the effective date of the rule and

form changes on March 24, 2025. The optional APIs include those discussed in the Proposing

Release—a submission API to allow filers to make both live and test submissions on EDGAR

(“submission API”); a submission status API to allow filers to check the status of an EDGAR

submission (“submission status API”); and an operational status API to allow filers to check

EDGAR operational status (“EDGAR operational status API”)—as well as 12 additional

optional APIs requested by commenters, detailed below.

Commenters recommended that optional APIs mirroring the functionality in the

dashboard be added to those discussed in the Proposing Release to reduce the burden associated

with manual dashboard tasks. 141 We will offer the majority of APIs that commenters requested,

140

See, e.g., Comment Letter of Andrew Danneffel (November 20, 2023) (“Danneffel II Comment Letter”) (“The

introduction of APIs to interact with EDGAR is very much welcome.”); Toppan Merrill Comment Letter (“The

proposed APIs accomplish the objectives of secure, efficient, and automated machine‐to‐machine

communication.”); Comment Letter of Chris V. (Nov 21, 2023) (“Chris V. Comment Letter”) (“For this

proposal, I believe specifically the API access outlined in Rule 10(d)(3) is the most crucial item which should

be added to the regulations.”).

141

See, e.g., Workiva Comment Letter (“All functionality provided by the EDGAR Dashboard should be available

via APIs....The administration burden and ongoing maintenance costs [of manually using the dashboard] will be

significant and could ultimately impact the cost burden on the filers”); XBRL II Comment Letter (“A complete

set of Filer Management APIs must be made available for effective management by filing agents and other

entities that support large numbers of registrants….This scale is not manageable using the Filer Management

which should largely address commenters’ concerns regarding account administrators’ manual

management of numerous individuals and accounts on the dashboard, as well as commenters’

request for enhanced EDGAR automation. For example, APIs will assist individuals who are

account administrators for multiple EDGAR accounts, such as investment company fund

families or asset-backed securities issuers with potentially hundreds of affiliated EDGAR

accounts. 142 We previously indicated that more APIs would be added if feasible, and the

additional APIs requested by commenters will be made available to enrolled filers when the

EDGAR Filer Management dashboard goes live on March 24, 2025. In addition, filers whose

application on amended Form ID is granted on or after March 24, 2025, will be able to connect

to the optional APIs. Collectively, the optional APIs will provide in machine-to-machine

connections the majority of functions on the dashboard for those filers that choose to manage

their EDGAR accounts in a more automated manner. 143 Additional APIs may be made available

in the future as feasible. Connection to APIs is optional.

If filers choose to connect to APIs, filers must comply with the requirement of paragraph

(d)(3) of Rule 10, as adopted, to authorize, through their account administrators, at least two

technical administrators, unless the filer uses the filer API tokens and API connections of its

delegated entity (so long as that entity is in compliance with the requirement to maintain at least

two technical administrators pursuant to paragraph (d)(3) of Rule 10), as discussed further

dashboard and would result in an overwhelming amount of email and incur a significant support burden and

associated costs.”); Chris V. Comment Letter (“My suggestion for improving the proposal is to provide the API

on a wider scale..”).

142

See, e.g., ICI Comment Letter (“EDGAR Next should provide a mechanism to provide for filers who have a

multi-filer structure, such as Funds.”); Toppan Merrill Comment Letter (“EDGAR Next should provide a

mechanism to affiliate and manage filers who have a multi‐filer structure.”).

143

The APIs will be available concurrently with EDGAR Filer Management dashboard availability – during

EDGAR business hours, from 6 a.m. to 10 p.m. Eastern Time, each day except Saturdays, Sundays, and Federal

holidays. See section II.D.

herein. Additionally, filers that choose to connect to the APIs must comply with the requirements

of the EDGAR Filer Manual as amended to present filer API tokens and user API tokens to

EDGAR generated on the dashboard on a periodic basis, unless filers use the filer API tokens

and API connections of their delegated entity (and the individual at the filer presents her user

API token, if required by that API). Filers, including delegated entities, that maintain at least two

technical administrators and connect to APIs must present a filer API token and the individual at

the filer must present a user API token to the APIs (if the relevant API requires a user API

token). If a filer chooses to use the filer API token and API connections of its delegated entity,

that filer’s individual account administrator or user must still present to the API a user API token

the individual generates on the dashboard (if the relevant API requires a user API token). 144

The API tokens represent a security requirement that eliminates the need for manually

entering individual account credentials and performing multifactor authentication each time a

submission is made. Instead, multifactor authentication and individual identification occurs when

the technical administrator logs into the dashboard to generate the filer API token annually and

when the relevant account administrator or user logs into the dashboard to generate a user API

token every 30 days, in accord with the time durations of the tokens specified in the EDGAR

Filer Manual as amended.

Filers who choose to connect to optional APIs will need to create certain software to

make technical connections to the APIs, as they would any other API. Commission staff are

providing filers with open-source code for a sample filing application that will facilitate filers’

connections to the three APIs noted in the Proposing Release in the EDGAR API Development

144

This requirement is included in the EDGAR Filer Manual, as amended. See amended EDGAR Filer Manual,

Volume I. We note that specific required inputs vary by API. For example, the EDGAR operational status API

will not require user API tokens, as discussed further below.

Toolkit (“API Toolkit”), available on SEC.gov. The sample filing application will provide

technical details and a working code base that could be either copied into existing filing

applications or used as a base for developing a new filing application. 145 Commission staff are

also offering filers a list of technical standards for the APIs, the expected inputs and outputs, and

information regarding whether only a filer API token or both filer and user API tokens are

required for particular APIs in the Overview of EDGAR Application Programming Interfaces

(“Overview of EDGAR APIs”), available on SEC.gov. We anticipate that the API Toolkit and

the Overview of EDGAR APIs will save filers time and effort in connecting to the optional APIs.

APIs That Commission Staff Will Provide

Submission API

Consistent with the discussion in the Proposing Release, the submission API will give

filers the option to submit test and live filer-constructed EDGAR submissions. 146 This API

should allow filers to rapidly and efficiently submit large numbers of filings in an automated

manner, instead of requiring them to manually log into EDGAR to make filings one at a time. 147

Successful connection to the submission API will transmit a filer-constructed submission to

EDGAR, at which point the submission will be subject to routine EDGAR validation checks and

145

The sample filing application code is a starting point for smaller filers that may not already have a filing

application and want to enter the API space. This sample code can serve as a troubleshooting guide/reference

material for all developers because it uses specific technologies (e.g., PostgreSQL, NodeJS, Angular) that are

well documented, standard, and can be understood by a mid-level programmer.

146

Currently, EDGAR accepts approximately 525 submission types, of which approximately 500 (95%) permit

filer construction.

147

Filers who do not wish to use the API to make filer-constructed submissions, and filers making other

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.