Rule2024-30494
EDGAR Filer Access and Account Management
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
December 27, 2024
Effective
March 24, 2025
Issuing agencies
Securities and Exchange Commission
Abstract
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-to-machine 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.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 248 (Friday, December 27, 2024)</title>
</head>
<body><pre>
[Federal Register Volume 89, Number 248 (Friday, December 27, 2024)]
[Rules and Regulations]
[Pages 106168-106229]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2024-30494]
[[Page 106167]]
Vol. 89
Friday,
No. 248
December 27, 2024
Part VI
Securities and Exchange Commission
-----------------------------------------------------------------------
17 Part 232, 239, 249, et al.
EDGAR Filer Access and Account Management; Final Rule
Federal Register / Vol. 89 , No. 248 / Friday, December 27, 2024 /
Rules and Regulations
[[Page 106168]]
-----------------------------------------------------------------------
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-to-machine
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
I. Introduction
II. Discussion
A. Individual Account Credentials
B. Individual Roles: Account Administrator, User, Technical
Administrator
1. Account Administrators
2. Users
3. Technical Administrators
C. Delegated Entities
1. Delegating Authority To File
2. Separation of Authority of Filer and Delegated Entity
3. Delegated Entities
4. Delegated Users
5. User Group Functionality at Delegated Entities
6. Technical Administrators at Delegated Entities
D. Hours of Operation of the Dashboard
E. Optional Application Programming Interfaces
1. APIs That Commission Staff Will Provide
2. API Tokens
F. Final Amendments to Rules and Forms
1. Rule 10 of Regulation S-T
2. Rule 11 of Regulation S-T
3. Form ID
G. EDGAR Filer Manual Changes
H. Transition Process
1. Enrollment Process
2. Compliance
III. Other Matters
IV. Economic Analysis
A. Baseline
B. Consideration of Benefits and Costs as Well as the Effects on
Efficiency, Competition, and Capital Formation
1. Benefits
2. Costs
3. Effects on Efficiency, Competition, and Capital Formation
C. Reasonable Alternatives
1. Add and Allow Bulk Confirmation for Related CIKs
2. Extend the ABSCOMP Process to Affiliated Entities
3. Retire the CCC for Filing Submissions
4. Requirements for Individual and Small Filers
5. Implementing Performance-Based Standards
V. Paperwork Reduction Act
A. Summary of Comment Letters on PRA Estimates
B. Form ID
C. The Dashboard
VI. Final Regulatory Flexibility Analysis
A. Need for and Objectives of the Rule and Form Amendments
B. Significant Issues Raised by Public Comments
C. Small Entities Subject to the Rule and Form Amendments
D. Projected Reporting, Recordkeeping, and Other Compliance
Requirements
E. Agency Action to Minimize Effects on Small Entities
Statutory Authority
Appendix A--Form ID
I. 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\
---------------------------------------------------------------------------
\1\ 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.''
\2\ 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'').
---------------------------------------------------------------------------
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
[[Page 106169]]
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.
---------------------------------------------------------------------------
\3\ For a discussion of the 2021 Request for Comment, please
refer to the Proposing Release.
\4\ Comment letters related to the 2021 Request for Comment are
available at <a href="https://www.sec.gov/comments/s7-12-21/s71221.htm">https://www.sec.gov/comments/s7-12-21/s71221.htm</a>.
\5\ Memoranda describing these meetings with SEC officials are
available at <a href="https://www.sec.gov/comments/s7-15-23/s71523.htm">https://www.sec.gov/comments/s7-15-23/s71523.htm</a>.
---------------------------------------------------------------------------
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 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 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.
---------------------------------------------------------------------------
\6\ The public comments we received are available at <a href="https://www.sec.gov/comments/s7-15-23/s71523.htm">https://www.sec.gov/comments/s7-15-23/s71523.htm</a>. A few commenters asserted
that the comment period was not sufficient and asked the Commission
to extend it. See 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.
---------------------------------------------------------------------------
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 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 unless the filer
arranges to use the filer API tokens and API connections of its
[[Page 106170]]
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.
---------------------------------------------------------------------------
\7\ In addition to the changes discussed below, Rule 10 is being
amended to implement certain clarifying and conforming changes. See
section II.F.1.
\8\ 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 <a href="http://Login.gov">Login.gov</a>, a
sign-in service of the U.S. Government that employs multifactor
authentication.
\9\ 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, <a href="https://www.filermanagement.edgarfiling.sec.gov">https://www.filermanagement.edgarfiling.sec.gov</a>.
\10\ 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.
\11\ 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.
\12\ 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.
\13\ 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.
\14\ 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.
\15\ 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.
\16\ 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.
\17\ 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.
---------------------------------------------------------------------------
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 rule and form amendments.\20\ We
are further amending the EDGAR Filer Manual to accord with the EDGAR
Next changes.
---------------------------------------------------------------------------
\18\ 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.
\19\ 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.
\20\ 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.
---------------------------------------------------------------------------
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, <a href="http://Login.gov">Login.gov</a> 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 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.
---------------------------------------------------------------------------
\21\ 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.
---------------------------------------------------------------------------
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 <a href="http://SEC.gov">SEC.gov</a>.\22\
---------------------------------------------------------------------------
\22\ See EDGAR Next-Improving Filer Access and Account
Management, U.S. Securities and Exchange Commission, available at
<a href="https://www.sec.gov/edgar/filer-information/edgar-next">https://www.sec.gov/edgar/filer-information/edgar-next</a>.
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\23\ A blackline of the changes to Volume I of the EDGAR Filer
Manual is available at <a href="http://www.sec.gov/rules-regulations">www.sec.gov/rules-regulations</a>.
---------------------------------------------------------------------------
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 who obtain individual account credentials. The EDGAR Filer
Manual is being amended to specify <a href="http://Login.gov">Login.gov</a> 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 machine-to-
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
[[Page 106171]]
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.
A. 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 <a href="http://Login.gov">Login.gov</a>, a secure sign-in service of the U.S.
General Services Administration.\24\ <a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> website to provide an email address, create a password,
and select a multifactor authentication option.\26\ The EDGAR Filer
Manual will specify that the email address provided to <a href="http://Login.gov">Login.gov</a> 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\
---------------------------------------------------------------------------
\24\ <a href="https://www.login.gov/">https://www.login.gov/</a>.
\25\ See <a href="http://Login.gov">Login.gov</a>, ``About us,'' at <a href="https://www.login.gov/about-us/">https://www.login.gov/about-us/</a>.
\26\ As of the date of this release, <a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> 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
<a href="http://Login.gov">Login.gov</a>, Authentication Options at <a href="https://www.login.gov/help/get-started/authentication-options/">https://www.login.gov/help/get-started/authentication-options/</a>. See also generally <a href="http://Login.gov">Login.gov</a>,
``Privacy and security: Our security practices,'' at <a href="https://login.gov/policy/our-security-practices/">https://login.gov/policy/our-security-practices/</a> for information on
<a href="http://Login.gov">Login.gov</a>'s security practices.
\27\ 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 <a href="http://Login.gov">Login.gov</a>. 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 <a href="http://Login.gov">Login.gov</a> 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.
---------------------------------------------------------------------------
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 <a href="http://Login.gov">Login.gov</a>,
the individual will be prompted to complete the multifactor
authentication option the individual selected when obtaining individual
account credentials at <a href="http://Login.gov">Login.gov</a>.\28\ Thus, through <a href="http://Login.gov">Login.gov</a>,
multifactor authentication for individual accounts will be required to
access EDGAR.
---------------------------------------------------------------------------
\28\ If the individual loses or forgets her <a href="http://Login.gov">Login.gov</a> password,
the individual can reset the password through <a href="http://Login.gov">Login.gov</a>, simplifying
and automating the process of password retrieval.
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\29\ See Exec. Order No. 14028 (2021), 60 FR 26633, 26636 (May
17, 2021).
\30\ See Digital Identity Guidelines: Authentication and
Lifecycle Management, National Institute of Standards and
Technology, NIST SP 800-63, available at <a href="https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final">https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final</a>, at section 4 of NIST SP 800-63B (``Any PII
or other personal information--whether self-asserted or validated--
requires multi-factor authentication.'').
---------------------------------------------------------------------------
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\
---------------------------------------------------------------------------
\31\ 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'').
---------------------------------------------------------------------------
Several commenters expressed concerns that the introduction of
individual account credentials could be disruptive or unduly burdensome
for individuals with reporting obligations pursuant to section 16 of
the Securities Exchange Act of 1934 (``Exchange Act'').\32\ For the
reasons discussed
[[Page 106172]]
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 <a href="http://Login.gov">Login.gov</a> for personal matters and
suggested that these individuals may not wish to use their existing
<a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> individual account credentials for
EDGAR.\35\ The email address will become the individual's username for
<a href="http://Login.gov">Login.gov</a> individual account credentials and will be used for
identification and notification purposes on EDGAR. Therefore, if an
individual currently has a <a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> individual account
credentials with the email address she wishes to use in connection with
EDGAR.\36\ This 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 <a href="http://Login.gov">Login.gov</a> personal
email address and password for personal matters. They will separately
use the <a href="http://Login.gov">Login.gov</a> individual account credentials they created for use
on EDGAR to log into EDGAR.
---------------------------------------------------------------------------
\32\ 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.'').
\33\ See SCG Comment Letter (``[T]here was also concern with
respect to the fact that <a href="http://Login.gov">Login.gov</a> 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.'').
\34\ 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 <a href="http://Login.gov">Login.gov</a> the email address that they intend to provide
to EDGAR, that will identify them to others on EDGAR, and that they
will use to receive communications from EDGAR.
\35\ See amended EDGAR Filer Manual, Volume I, at section 3(a).
\36\ By contrast, if individuals currently have <a href="http://Login.gov">Login.gov</a>
accounts used in connection with EDGAR, they may choose to rely upon
those existing <a href="http://Login.gov">Login.gov</a> individual account credentials.
---------------------------------------------------------------------------
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 <a href="http://Login.gov">Login.gov</a> 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\
---------------------------------------------------------------------------
\37\ 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.'').
\38\ 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.
\39\ 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
<a href="http://Login.gov">Login.gov</a> and manage the filer's account on the dashboard. In summary,
the individual or single-member company filer would not need to obtain
<a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> multifactor authentication process as it is
substantially the same as the process used 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\
---------------------------------------------------------------------------
\40\ 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.'').
\41\ See sections II.B.1 and II.B.2.
---------------------------------------------------------------------------
The commenter further raised issues surrounding the security of
<a href="http://Login.gov">Login.gov</a>.\42\ The matters raised by the commenter pertain to
<a href="http://Login.gov">Login.gov</a>'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
<a href="http://Login.gov">Login.gov</a>, however, is to provide identity assurance level 1 (``IAL1'')
services, which do not require presentation of such sensitive
personally identifiable information. To obtain individual account
credentials from <a href="http://Login.gov">Login.gov</a> for EDGAR, the
[[Page 106173]]
individual need only provide her email address, create a password, and
select a multifactor authentication method. The security of <a href="http://Login.gov">Login.gov</a>'s
provision of IAL1 services has not been called into question, and as
noted above, numerous Federal and State agencies successfully use
<a href="http://Login.gov">Login.gov</a> on an ongoing basis.
---------------------------------------------------------------------------
\42\ See SCG Comment Letter (``Given that the security of
<a href="http://Login.gov">Login.gov</a> has been questioned by Congress and the Internal Revenue
Service has expressed reservations about using the platform, the
Commission should not mandate <a href="http://Login.gov">Login.gov</a> as the sole platform that
registrants and their Section 16 filers may use for multi-factor
authentication.'').
\43\ See ``GSA Misled Customers on <a href="http://Login.gov">Login.gov</a>'s Compliance with
Digital Identity Standards,'' Press Release, Office of the Inspector
General, U.S. General Services Administration, available at <a href="https://www.gsaig.gov/content/gsa-misled-customers-logingovs-compliance-digital-identity-standards">https://www.gsaig.gov/content/gsa-misled-customers-logingovs-compliance-digital-identity-standards</a> (``GSA knowingly billed IAL2 customer
agencies over $10 million for services, including alleged IAL2
services that did not meet IAL2 standards.'')
---------------------------------------------------------------------------
Other commenters suggested that EDGAR provide filers with the
option to continue to use a password and CCC instead of <a href="http://Login.gov">Login.gov</a>
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 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\
---------------------------------------------------------------------------
\44\ 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.'')
\45\ 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).
\46\ Further, the commenter appeared to base the comment in part
upon the assumption that there would be a one-month preparation
period prior to enrollment in EDGAR Next. Instead, the Commission is
offering filers a six-month preparation period which we believe will
allay the commenter's expressed concerns.
\47\ 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 <a href="http://Login.gov">Login.gov</a>
accounts and then enroll through the EDGAR Next dashboard.'').
\48\ In addition, it is not technically feasible for EDGAR to
extend legacy filing processes for one subset of filers.
---------------------------------------------------------------------------
Several commenters suggested that filers should have the option to
use alternatives to <a href="http://Login.gov">Login.gov</a> as technology evolves.\49\ Another
commenter requested alternatives to <a href="http://Login.gov">Login.gov</a> in the event the service
is unavailable but did not suggest what alternatives were
appropriate.\50\ Another commenter approved of the choice of
<a href="http://Login.gov">Login.gov</a>.\51\ <a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a> 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.
---------------------------------------------------------------------------
\49\ 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'').
\50\ 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
<a href="http://Login.gov">Login.gov</a> is not available.'').
\51\ See Toppan Merrill Comment Letter (``<a href="http://Login.gov">Login.gov</a> 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.'').
---------------------------------------------------------------------------
Some commenters raised concerns that requiring individual account
credentials for EDGAR access could be burdensome and confusing in
specific situations, such as where 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.
---------------------------------------------------------------------------
\52\ 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).
---------------------------------------------------------------------------
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 <a href="http://Login.gov">Login.gov</a> 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 attorney,
as discussed above. Second, she could log
[[Page 106174]]
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.
---------------------------------------------------------------------------
\53\ See Workiva Comment Letter.
\54\ See XBRL II Comment Letter.
---------------------------------------------------------------------------
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 security at U.S.
Federal agencies, such as those described in the executive order and
the NIST digital identity guidelines.
---------------------------------------------------------------------------
\55\ 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).
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\56\ See amended EDGAR Filer Manual, Volume I, at section 3(a).
---------------------------------------------------------------------------
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 of
individual account credentials among multiple individuals undermines
the purpose of multifactor authentication, which is intended to be
specific to a known individual.
---------------------------------------------------------------------------
\57\ 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).
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\58\ Filers enrolling during the three-month period after the
compliance date will be required to present the CIK, CCC, and
passphrase to complete enrollment.
---------------------------------------------------------------------------
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
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.
---------------------------------------------------------------------------
\59\ 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.'').
\60\ Specifically, this will include the filer's account
administrators, users, delegated administrators, and delegated
users.
---------------------------------------------------------------------------
One commenter indicated that certain <a href="http://Login.gov">Login.gov</a> multifactor
authentication methods are restricted in certain countries.\61\ While
we understand that not all the methods for multifactor authentication
on <a href="http://Login.gov">Login.gov</a> may be available to those in certain countries, we note
that <a href="http://Login.gov">Login.gov</a> offers individuals several different authentication
methods, including a security key, 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
[[Page 106175]]
<a href="http://Login.gov">Login.gov</a>.\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 <a href="http://Login.gov">Login.gov</a> to satisfy the multifactor
authentication requirement.
---------------------------------------------------------------------------
\61\ See SCG Comment Letter (``In addition, some features of
<a href="http://Login.gov">Login.gov</a> (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.'').
\62\ Current <a href="http://Login.gov">Login.gov</a> 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 <a href="http://Login.gov">Login.gov</a>,
Authentication Options at <a href="https://www.login.gov/help/get-started/authentication-options/">https://www.login.gov/help/get-started/authentication-options/</a>.
_____________________________________-
Another commenter asserted that in lieu of individual account
credentials and multifactor authentication, as contemplated in the
Proposing Release, <a href="http://Login.gov">Login.gov</a> should allow EDGAR authentication via
EDGAR Next API keys.\63\ API keys alone, however, do not provide the
security assurances of multifactor authentication.
---------------------------------------------------------------------------
\63\ See Block Transfer Comment Letter (``[W]e respectfully
submit to the Commission that <a href="http://Login.gov">Login.gov</a> might present material
benefits to issuers if it replaced the proposed security interface
using EDGAR Next API keys.'').
---------------------------------------------------------------------------
B. 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\
---------------------------------------------------------------------------
\64\ 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).
\65\ 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.
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\66\ See the EDGAR Next page on <a href="http://SEC.gov">SEC.gov</a> for guidance regarding
actions on the dashboard.
[GRAPHIC] [TIFF OMITTED] TR27DE24.011
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.
[[Page 106176]]
[GRAPHIC] [TIFF OMITTED] TR27DE24.012
1. 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.
---------------------------------------------------------------------------
\67\ 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.'').
---------------------------------------------------------------------------
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 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 ID or an existing
filer's enrollment as the filer's EDGAR POC. The filer, through its
account administrator, may
[[Page 106177]]
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.
---------------------------------------------------------------------------
\68\ 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.
\69\ 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.'').
\70\ 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.'').
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\71\ 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. 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 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.
---------------------------------------------------------------------------
\72\ A separate process of enrollment will be employed to
transition existing filers, as discussed in section II.H.
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\73\ 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.'').
---------------------------------------------------------------------------
As contemplated in the proposal, entity applicants will be able to
authorize as account 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.
---------------------------------------------------------------------------
\74\ 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.
\75\ 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. . . .'').
---------------------------------------------------------------------------
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
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
[[Page 106178]]
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.
---------------------------------------------------------------------------
\76\ 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.'').
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\77\ 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.'').
---------------------------------------------------------------------------
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. 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.
---------------------------------------------------------------------------
\78\ 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.'').
---------------------------------------------------------------------------
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.''
b. 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 single-member
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
[[Page 106179]]
necessary (up to a maximum of 20) to ensure that an account
administrator is always available to take necessary actions.
---------------------------------------------------------------------------
\79\ 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.'').
\80\ See Workiva Comment Letter (``For individuals and single-
member companies, please clarify if the one minimum administrator
must be the individual himself or herself.'').
\81\ See Toppan Merrill Comment Letter (``We suggest that
additional warnings are provided when the `single-member 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'').
---------------------------------------------------------------------------
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 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\
---------------------------------------------------------------------------
\82\ 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.
---------------------------------------------------------------------------
c. 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 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.
---------------------------------------------------------------------------
\83\ 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.'').
\84\ 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.'').
---------------------------------------------------------------------------
d. Annual Confirmation
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
[[Page 106180]]
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 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.
---------------------------------------------------------------------------
\85\ 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.).
\86\ 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).
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\87\ 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[.]'').
\88\ See supra text following note 52.
---------------------------------------------------------------------------
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
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
[[Page 106181]]
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.
---------------------------------------------------------------------------
\89\ 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 a nd removing information from an existing account.'').
\90\ 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.
---------------------------------------------------------------------------
e. 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.
---------------------------------------------------------------------------
\91\ 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.'')
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\92\ 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.'').
---------------------------------------------------------------------------
2. 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 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.
---------------------------------------------------------------------------
\93\ Commenters were generally supportive of the user role. See
comments by Toppan Merrill, DFIN, SIFMA, and XBRL II.
---------------------------------------------------------------------------
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 login CIK at any time
to any other account for which they are authorized.
---------------------------------------------------------------------------
\94\ 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).
---------------------------------------------------------------------------
a. 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 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 <a href="http://Login.gov">Login.gov</a> 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.
---------------------------------------------------------------------------
\95\ 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.'').
\96\ 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).
---------------------------------------------------------------------------
b. 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 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
[[Page 106182]]
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\
---------------------------------------------------------------------------
\97\ 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.'').
\98\ See XBRL II Comment Letter (``We believe that the limit of
500 authorized users per filer is sufficient.'').
\99\ 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.
---------------------------------------------------------------------------
3. 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 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.
---------------------------------------------------------------------------
\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-to-machine 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 <a href="http://Login.gov">Login.gov</a> machine-to-machine authentication
system may bestow upon on our cybersecurity interests both
domestically and abroad. . . .'').
---------------------------------------------------------------------------
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 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\
---------------------------------------------------------------------------
\106\ See generally section II.C.6.
\107\ 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.
---------------------------------------------------------------------------
a. 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.
---------------------------------------------------------------------------
\108\ 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.'').
---------------------------------------------------------------------------
b. Becoming a Technical Administrator
To authorize an individual as a technical administrator, an account
administrator will add 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.
c. 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
[[Page 106183]]
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 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.
---------------------------------------------------------------------------
\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 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.
---------------------------------------------------------------------------
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 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\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
C. Delegated Entities
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\
---------------------------------------------------------------------------
\115\ See supra note 60.
---------------------------------------------------------------------------
1. 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.
---------------------------------------------------------------------------
\116\ An optional delegation API will be offered in addition to
the delegation capabilities of the dashboard.
---------------------------------------------------------------------------
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 they choose.
Commenters generally supported the ability to delegate,\117\
although various commenters raised concerns about certain situations or
recommended
[[Page 106184]]
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.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\120\ See Workiva Comment Letter (``[We] also suggest adding an
option to allow filing agent-type CIKs to auto-accept
delegations.''); XBRL II Comment Letter (asserting that filing
agents/vendors should be able to request delegation, which could
``be automatically approved by the registrant.'').
---------------------------------------------------------------------------
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, which
means the account administrator at the delegated entity must first log
into EDGAR using her individual account credentials and perform
multifactor authentication.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
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 role-based 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.
---------------------------------------------------------------------------
2. 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
[[Page 106185]]
take dashboard actions on behalf of the filer.
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\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).'').
---------------------------------------------------------------------------
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\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
3. 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,a nd 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.
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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
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 on the dashboard.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
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.
[[Page 106186]]
[GRAPHIC] [TIFF OMITTED] TR27DE24.013
4. 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.
---------------------------------------------------------------------------
\133\ For this reason, delegated administrators could not be
authorized as delegated users regarding the delegating filer,
because doing so would be redundant.
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\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.'').
\136\ See text following note 118 (discussing the dashboard's
bulk delegation functionality).
---------------------------------------------------------------------------
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.
5. 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.
[[Page 106187]]
[GRAPHIC] [TIFF OMITTED] TR27DE24.014
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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\
---------------------------------------------------------------------------
\137\ See supra note 92 and accompanying and following text.
---------------------------------------------------------------------------
6. 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 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.
D. 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
[[Page 106188]]
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 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.
---------------------------------------------------------------------------
\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
DC 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).
---------------------------------------------------------------------------
E. 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.
---------------------------------------------------------------------------
\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.'').
---------------------------------------------------------------------------
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, 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.
---------------------------------------------------------------------------
\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 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.
---------------------------------------------------------------------------
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 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\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
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 Toolkit (``API Toolkit''), available on
<a href="http://SEC.gov">SEC.gov</a>. The sample filing application will
[[Page 106189]]
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 <a href="http://SEC.gov">SEC.gov</a>. We
anticipate that the API Toolkit and the Overview of EDGAR APIs will
save filers time and effort in connecting to the optional APIs.
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
1. APIs That Commission Staff Will Provide
a. 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 processing.
---------------------------------------------------------------------------
\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 types of
submissions, could continue to file through the web-based EDGAR
filing websites. Whether submissions were made through the API or
the EDGAR filing websites, filers will specify the CIK for which
they are making submissions. That CIK number will be reflected in
the accession number associated with those submissions. Filers could
change the login CIK reflected in the accession number at any time
to any other CIK for which the filer is authorized to file on EDGAR.
For example, a filing agent could choose to submit filings for a
client filer using its own login CIK, or by using its client filer's
login CIK.
---------------------------------------------------------------------------
One commenter suggested the introduction of submission endpoints
specific to major forms offered to filers.\148\ The commenter asserted
this could be used to control filing permissions for specific forms so
that, for example, a filer could delegate permissions for only certain
specific form types. Although some filers may wish to engage in limited
delegations of authority, there is no current plan to introduce that
level of granularity to EDGAR. Under EDGAR Next, a filer's account
administrators will receive a notification when the delegated entity
makes a submission for the filer, and if that submission is made
without the filer's authorization, the filer's account administrators
will be able to remove the delegated entity's authority to make
submissions on the filer's behalf and take other corrective actions.
Moreover, providing form-specific filing permissions could be
logistically difficult to administer as EDGAR currently accepts 525
submission types.
---------------------------------------------------------------------------
\148\ See Block Transfer Comment Letter (``We respectfully
present to the Commission that there should be submission endpoints
specific to major forms offered to filers. Specific routes for each
filing enable the Commission to check for route-specific endpoint
authorization. That way, an issuer that authorizes another filer to
submit automated insider transaction reports does not have to worry
about the agent submitting a Form 10-K.'').
---------------------------------------------------------------------------
b. Submission Status API
As discussed in the Proposing Release, a submission status API will
allow filers to leverage their filing application to simultaneously
check the status of multiple submissions in a batch process, instead of
manually logging into EDGAR and individually checking the status of
each submission. The submission status API will indicate whether each
submission has been submitted and accepted, but not yet publicly
disseminated; \149\ submitted and accepted, and publicly disseminated;
or submitted and suspended.
---------------------------------------------------------------------------
\149\ Generally, filings are first accepted and then
subsequently disseminated. Certain filings, however, remain
nonpublic and are never disseminated. Therefore, those filings never
progress from accepted to disseminated status.
---------------------------------------------------------------------------
One commenter requested that the submission status API be modified
to provide additional information so that filers could more fully
understand the exact status of their EDGAR submissions.\150\ As
requested by the commenter, the submission status API will be enhanced
to provide all information currently contained in EDGAR submission
notifications.
---------------------------------------------------------------------------
\150\ See Workiva Comment Letter (``Missing information
includes, but is not limited to, warning/error labels (as shown on
<a href="https://www.sec.gov/edgar/messages">https://www.sec.gov/edgar/messages</a>), the number of documents
processed, the received and filing dates, series/class information,
Section 16 reporting owner/issuer details, Subject Company, file
number(s), and Item Submission accession number and type information
for combined filings. The current Submission Notification HTML
document contains this information and the API should be modified to
include this document . . . .'').
---------------------------------------------------------------------------
c. EDGAR Operational Status API
As discussed in the Proposing Release, an EDGAR operational status
API will allow filers to leverage their filing application to check the
operational status of EDGAR at any given time. The EDGAR operational
status API will indicate whether EDGAR is fully operational,
unavailable (after business hours), or not fully operational in
whatever regard at that point in time (for example, if EDGAR is not
disseminating to <a href="http://SEC.gov">SEC.gov</a>). We did not receive any comments specifically
regarding the EDGAR operational status API.
In addition to the APIs discussed in the Proposing Release, the
following APIs will be offered in response to commenter requests, as
described below.
d. Filing Credentials Verification API
Several commenters requested the addition of an API to allow filers
to confirm the validity of all credentials involved in an API-based
filing.\151\ One commenter asserted that this API would be used
thousands of times per day and would help detect authorization errors
prior to submission, which would in turn reduce the amount of invalid
filing submissions and reduce the load on both filing software and
EDGAR systems.\152\ A ``filing credentials verification API'' will be
added, as requested by commenters, which should assist filers in
verifying the status of their credentials, allowing them to accurately
schedule and submit filings. The API will indicate if the provided
credentials have filing permissions with regarding the provided CIK,
and if so, will also provide the upcoming account confirmation deadline
and the expiration dates of the provided API tokens.
---------------------------------------------------------------------------
\151\ See, e.g., Workiva Comment Letter (``We suggest adding an
API which would return specific, comprehensive information about the
status of all credentials involved in an API-based filing.'');
Danneffel II Comment Letter (``I'd like to suggest an additional API
be added that tests the validity of a user/filer token combination .
. . ., The proposed API would check:--If the user token is valid
(exists and is not expired)--If the filer token is valid (exists and
is not expired)--If the user token is authorized to file using the
filer token . . . .'').
\152\ See Workiva Comment Letter (``This new API would be
accessed prior to every filing submission, so it could be expected
to be called thousands of times per day--although detecting
authorization errors prior to submitting a filing would reduce the
amount of invalid filing submissions and would reduce the load on
both filing software and EDGAR systems.'').
---------------------------------------------------------------------------
[[Page 106190]]
e. APIs To View Individuals, Add Individuals, Remove Individuals, and
Change Roles
Several commenters requested the addition of optional APIs to
replicate dashboard functionality to allow filing agents and other
entities that support large numbers of registrants to more easily
manage filer accounts.\153\ Separate optional APIs will be provided so
that filers may view individuals authorized for a CIK, add individuals,
remove individuals, and change roles for individuals.\154\
Collectively, these APIs should enable filing agents and other entities
that support large numbers of filers to rapidly and efficiently manage
individual authorizations and roles for those filers.
---------------------------------------------------------------------------
\153\ See Workiva Comment Letter (``All functionality provided
by the EDGAR Dashboard should be available via APIs. While the
Dashboard may be sufficient for individual registrants, it will be
unworkable for many filing agents.''); 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 dashboard and would result in
an overwhelming amount of email and incur a significant support
burden and associated cost.'').
\154\ In addition, APIs will be provided related to delegation
and CCCs.
---------------------------------------------------------------------------
f. APIs To Send Delegation Invitations, Request Delegation Invitations,
and View Delegations
As discussed above, commenters requested the addition of optional
APIs to replicate dashboard functionality to allow filing agents and
other entities that support large numbers of registrants to more easily
manage filer accounts.\155\ Separate optional APIs will be provided to
allow filers to send delegation invitations to prospective delegated
entities, request delegation invitations from prospective delegating
filers, and view delegations currently in place (including both
delegations received from filers and also delegations provided to
delegated entities). Collectively, these optional APIs should enable
filing agents and other entities that support large numbers of filers
to manage delegations rapidly and efficiently for those filers.
---------------------------------------------------------------------------
\155\ See supra note 141153.
---------------------------------------------------------------------------
g. APIs To View Filer Account Information, Generate CCC, and Create
Custom CCC
Several commenters requested the addition of an optional API to
make available on a machine-to-machine basis the same functionality
that is currently provided within the ``Retrieve/Edit Data'' section of
the EDGAR Filing website.\156\ That functionality includes, but is not
limited to, the ability to view/edit filer 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. In addition, the fee-related aspects of this
functionality raise unique technical challenges that make providing
APIs for those functions more difficult due to the current systems and
processes surrounding payment and fee information.\157\ For those
reasons, separate APIs will not be added at this time for each of the
functions currently provided in the ``Retrieve/Edit Data'' section of
the EDGAR Filing website.
---------------------------------------------------------------------------
\156\ See XBRL II Comment Letter (``All functionality provided
under the Retrieve/edit data section of the EDGAR site should have
an equivalent API implementation. . . .''); Toppan Merrill Comment
Letter (``Ideally, all functionality that is currently available
within the `Retrieve/Edit' data under a CIK within EDGAR will be
available through an API in EDGAR Next.'').
\157\ Filing fee information will remain in the ``Retrieve/Edit
Data'' section of the EDGAR Filing website; it will not be
accessible on the dashboard.
---------------------------------------------------------------------------
To address commenter concerns, however, a ``view filer account
information API,'' as well as a ``generate CCC API'' and a ``create
custom CCC API,'' will be added. The optional view filer account
information API will allow filers to view the filer's name, contact
information, CCC, CIK type (company, single-member company, or
individual), and next confirmation date. The optional generate CCC and
create custom CCC APIs will allow filers to generate a new CCC at any
time to enhance filer security without causing filing delays.
h. Enrollment API
To facilitate the requirement that existing filers enroll in EDGAR
Next, an optional API designed to automate the enrollment process will
be added. As stated in the Proposing Release, filers may enroll in
EDGAR Next either through, (a) manual enrollment of single accounts on
an account-by-account basis or (b) enrollment of multiple accounts
simultaneously, by completing and uploading a spreadsheet of up to 100
filers (100 rows) per bulk enrollment. Several commenters expressed
concerns regarding the volume and complexity of enrollment and
requested that some form of automation or increased flexibility be
provided regarding the enrollment process.\158\ The ``enrollment API''
should help address these concerns by streamlining the enrollment
process.
---------------------------------------------------------------------------
\158\ See, e.g., Workiva Comment Letter (``[W]e suggest
automatically enrolling the current POC as a super administrator by
default. . . . We highly recommend that the initial transition
should include preloaded delegations based on filing history, with
the option of automatic acceptance by filing agents. . . .''); XBRL
II Comment Letter (``We recommend that the CSV limit be increased to
500, from the proposed limit of 100.'').
---------------------------------------------------------------------------
2. API Tokens
For filers that opt to connect to APIs, filer API tokens and user
API tokens if the relevant API requires presentation of a user API
token, will be required by the EDGAR Filer Manual as amended, as
discussed in the Proposing Release. The use of tokens to connect to
optional APIs is a security requirement designed to minimize the
potential for unauthorized access to filers' accounts on EDGAR.
As discussed in the Proposing Release, the EDGAR Filer Manual will
be amended to require that filers that connect to the optional APIs
have a technical administrator generate a filer API token on the
dashboard to authenticate the filer. The filer API token will remain
valid for up to one year. In a change to what was discussed in the
proposal, a filer will be allowed to use its delegated entities' filer
API tokens and API connections (and rely upon its delegated entities'
technical administrators), so long as the filer's delegated entity has
authorized at least two technical administrators pursuant to paragraph
(d)(3) of Rule 10 and the individual at the filer using its delegated
entity's filer API tokens and API connections provides a valid user API
token if the relevant API requires presentation of a user API token, as
set forth below. Further, as discussed in the Proposing Release, the
EDGAR Filer Manual will be amended to require that an individual user
or account administrator generate a user API token on the dashboard to
authenticate herself. In a change to the discussion in the Proposing
Release indicating that the EDGAR Filer Manual would require that the
user API token would remain valid for up to one year so long as the
user logged into EDGAR at least every 30 days, the EDGAR Filer Manual
will specify that the user API token will remain valid for 30 days from
the time the token is generated.
One commenter recommended that a filer be able to use the filer API
token generated by the filer's delegated entity.\159\ This suggestion
will be
[[Page 106191]]
implemented to make the optional APIs more accessible for smaller
filers. As discussed above, filers may use their delegated entity's API
connections and filer API tokens so long as the delegated entity has
authorized at least two technical administrators pursuant to paragraph
(d)(3) of Rule 10. Filers that do so will not need to authorize their
own technical administrators or obtain and maintain their own filer API
tokens. Individuals at these filers must, however, supply their own
user API tokens, if the relevant API requires presentation of a user
API token. As a result, smaller filers that may not have the resources
to develop API connections or employ their own technical
administrators, but who nevertheless would like their personnel to
interact with EDGAR through APIs, may use the APIs that their delegated
entity develops and maintains.
---------------------------------------------------------------------------
\159\ Workiva Comment Letter (``[T]he proposed delegation
scenario is not well suited for automated filing solutions, since
while the filing software can use its filer token, an employee of
the filing software provider would not typically be involved to
provide their user token. One solution would be to allow the
registrant's authorized user to use their user token with the
delegated filing software's filer token.'').
---------------------------------------------------------------------------
Another commenter expressed concern that expiring API tokens could
frustrate the ability of filers to plan ahead to make filings and
suggested that the Commission provide an API to allow filers to
programmatically check expiration dates for relevant filer API tokens
and user API tokens.\160\ As discussed further above, an optional
filing credentials API will be offered so that filers can check filing
credentials, including information regarding API token expiration dates
and account confirmation deadlines.
---------------------------------------------------------------------------
\160\ See XBRL II Comment Letter (``We also suggest that the
Commission give users the ability to see information about the
token, for example what is the upcoming expiration date. This could
be executed through an API that provides visibility into whether the
token should work, and if it is not functional, an explanation as to
why it is not working.'').
---------------------------------------------------------------------------
Many commenters objected to the 30-day login requirement for the
user API token discussed in the proposal and stated that it would be
especially burdensome for infrequent filers.\161\ One commenter also
expressed concerns about the complexity and multiple layers of
requirements contemplated for user API tokens, citing the one-year
validity period and 30-day login requirements.\162\ Another commenter
supported the 30-day login requirement as being justified in terms of
providing additional security.\163\
---------------------------------------------------------------------------
\161\ See, e.g., XBRL II Comment Letter (``[T]he requirement to
log into an EDGAR website, interactively, every 30 days means that
many Section 16 reporting owners will be continuously
inactivated.''); SIFMA Comment Letter (``[W]e recommend that EDGAR
Next access credentials not be removed for mere inactivity, which
the Commission indicates would happen with API tokens that are not
used during a 30 day period.''); Workiva Comment Letter (``According
to our customer survey, about 72% of the respondents indicated that
[the 30-day login requirement for user API tokens] poses a
significant burden or risk to their filing teams. We strongly
recommend that the Commission eliminate this requirement.'').
\162\ See XBRL II Comment Letter (``[W]e are concerned about the
multiple layers of requirements for the token API, for example, the
expiration and 30-day login requirements, which will be challenging,
particularly for sporadic filers.'').
\163\ See Chris V. Comment Letter (``In the vein of additional
security, the proposal as written also currently suggests requiring
monthly logins to maintain access to an API access code which is
open for one year. I feel this could be considered heavyhanded in
comparison to the fairly lax standards which exist today, but I do
think it's worth the additional security and expectation from those
submitting data.'').
---------------------------------------------------------------------------
We considered these comments as well as the need to enhance system
security. As a result, in a change to what was discussed in the
Proposing Release, the EDGAR Filer Manual as amended will specify that
the user API token will expire 30 days after the individual generates
the token. The Proposing Release by contrast contemplated that the user
API token would remain valid for one year so long as the user logged
into the dashboard every 30 days. Thus, rather than logging in every 30
days to keep the user API token active, as discussed in the Proposing
Release, the individual is required to log in every 30 days to generate
a new user API token. The shorter duration of the user API token will
enhance the security of APIs, especially in light of the annual
duration of the filer API token. Shorter validity periods and more
frequent expiration dates limit the risk exposure of a token being lost
or stolen during the validity period, and thus more frequent expiration
dates are generally preferable from a security perspective. Separately,
the 30-day duration of the user API token avoids the potential
confusion posed by a token that persists for one year only if the user
logs into EDGAR every 30 days, a concern expressed by one commenter
noted above.\164\ We note that an optional API will be offered, as
requested by commenters and discussed above, to allow filers easily to
retrieve the expiration dates of the filer API token and user API
token.
---------------------------------------------------------------------------
\164\ See XBRL II Comment Letter (``[W]e are concerned about the
multiple layers of requirements for the token API, for example, the
expiration and 30-day login requirements, which will be challenging,
particularly for sporadic filers.'').
---------------------------------------------------------------------------
While we understand the concerns raised by commenters, we do not
think it is unduly burdensome for section 16 and other periodic filers
who choose to make submissions through APIs to log into the dashboard
and generate a new user API token once per month or otherwise prior to
making an infrequent filing. Further, as is the case currently, the
individual making the submission need not be the filer itself. Section
16 and other periodic filers could authorize through powers of attorney
relevant individuals at their filing agents or other representatives as
account administrators, eliminating the need for the section 16 or
other periodic filer to obtain individual account credentials or
otherwise interact with the dashboard. Alternatively, section 16 and
other periodic filers could delegate authority to file to one of these
entities (so long as that entity has an EDGAR account), thereby
eliminating the need for the section 16 filer herself to log into the
dashboard to generate user API tokens. In addition, as noted elsewhere
in this release, generating a user API token is a straightforward
process accomplished on the dashboard, and we estimate that a user API
token could be generated within approximately one minute of logging
into the dashboard. Moreover, the ability of a filer to authorize
multiple account administrators and users, each with a user API token
expiring at a different time, lessens concerns about the need to
generate a new user API token for a particular user when a filing
deadline is approaching.
A commenter suggested that the SEC allow the use of
``organizational user tokens'' that would represent the filer as a
whole, as opposed to identifying a specific individual.\165\ Similarly,
another commenter suggested that filers using third-party filing
software should be able to submit filings by presenting a user API
token belonging to an individual at the third-party filing software
company, so that the individual who was making the filing would not
need to obtain a user API token to identify herself.\166\ We decline to
implement these suggestions because they would frustrate the
Commission's objective of identifying the individual making the filings
and taking actions on EDGAR through APIs.
---------------------------------------------------------------------------
\165\ See Workiva Comment Letter (indicating that the SEC should
allow an organizational user token that represents the organization
as a whole and that could be managed the same way as an individual
user API token).
\166\ See Comment Letter of Martin Francisco (November 21, 2023)
(``Would it be deemed permissible to use a single user token
belonging to the administrator of a third-party filing solution to
submit filings created by independent users of that third-party
filing solution? Such a deployment would make it e
[…truncated; see source link]Indexed from Federal Register on December 27, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.