Document headings vary by document type but may contain the following:
See the Document Drafting Handbook for more details.
AGENCY:
Transportation Security Administration (TSA), Department of Homeland Security (DHS).
ACTION:
Final rule.
SUMMARY:
The Department of Homeland Security (DHS) is amending the REAL ID regulations to waive, on a temporary and State-by-State basis, the regulatory requirement that mobile or digital driver's licenses or identification cards (collectively “mobile driver's licenses” or “mDLs”) must be compliant with REAL ID requirements to be accepted by Federal agencies for official purposes, as defined by the REAL ID Act, when full enforcement of the REAL ID Act and regulations begins on May 7, 2025.
DATES:
Effective date: This rule is effective November 25, 2024.
Incorporation by Reference: The incorporation by reference of certain material listed in the rule is approved by the Director of the Federal Register as of November 25, 2024. The incorporation by reference of certain other material listed in the rule was approved by the Director of the Federal Register as of January 14, 2016.
FOR FURTHER INFORMATION CONTACT:
Technical questions: George Petersen, Senior Program Manager, REAL ID Program, Enrollment Services and Vetting Programs, Transportation Security Administration; telephone: (571) 227-2215; email: george.petersen@tsa.dhs.gov.
Legal questions: Anurag Maheshwary, Attorney Advisor, Office of Chief Counsel, Transportation Security Administration; telephone: (571) 227-4812; email: anurag.maheshwary@tsa.dhs.gov.
SUPPLEMENTARY INFORMATION:
Availability of Rulemaking Document
You can find an electronic copy of this rulemaking using the internet by accessing the Government Publishing Office's web page at https://www.govinfo.gov/app/collection/FR/ to view the daily published Federal Register edition or accessing the Office of the Federal Register's web page at https://www.federalregister.gov. Copies are also available by contacting the individual identified for “Technical Questions” in the FOR FURTHER INFORMATION CONTACT section. Make sure to identify the docket number of this rulemaking.
Abbreviations and Terms Used in This Document
AAMVA—American Association of Motor Vehicle Administrators
CA/Browser Forum—Certification Authority Browser Forum
CISA—Cybersecurity and Infrastructure Security Agency
DHS—U.S. Department of Homeland Security
EDL—Enhanced driver's license and identification card
FIPS—Federal Information Processing Standards
HSM—Hardware security module
IBR—Incorporation by reference or Incorporate by reference
IEC—International Electrotechnical Commission
ISO—International Organization for Standardization
IT—Information technology
mDL—Mobile driver's license and mobile identification card
NIST—National Institute for Standards and Technology
NPRM—Notice of proposed rulemaking
OFR—Office of Federal Register
OMB—Office of Management and Budget
PUB—Publication
RFI—Request for information
SP—Special publication
TSA—Transportation Security Administration
Table of Contents
I. Executive Summary
A. Purpose of this Rulemaking
B. Summary of the Major Provisions
C. Need for a Multi-Phased Rulemaking
D. Costs and Benefits
II. Background
A. REAL ID Act, Regulations, and Applicability to mDLs
B. Rulemaking History
C. mDL Overview
D. Industry Standards and Government Guidelines for mDLs
III. General Discussion of the Rulemaking
A. Changes Between NPRM and Final Rule
B. Summary of Regulatory Provisions
C. Specific Provisions
D. Impacted Stakeholders
E. Use Cases Affected by This Rule
F. Severability
IV. Discussion of Comments
A. Waiver Eligibility
B. Conditions on Federal Agencies Accepting mDLs
C. Waiver Application Criteria
D. TSA Waiver Application Guidance
E. General Concerns About mDLs
F. Scope of Rulemaking and mDL Acceptance
G. Privacy
H. Waiver Validity Period and Renewals
I. Vendor and Technology “Lock-in” Effects
J. Pseudonymous Validation and On-Device Biometric Matching
K. Access to Standards
L. Standards and Standards Development Generally
M. TSA's Identity Verification Policies
N. Paperwork Reduction Act
O. Legal Authority
P. Economic Impact Analysis
Q. Communicating Status of Waiver; System Disruptions
R. Impact of Waiver on States Currently Testing mDLs With TSA
S. Notice for Changes to State mDL Issuance Processes
T. Clarification Regarding “Days”
U. Audit Requirements
V. Appendix A to Subpart A: mDL Issuance Requirements
W. Protection of Sensitive Security Information in Waiver Applications
V. Consultation With States and the Department of Transportation
VI. Regulatory Analyses
A. Economic Impact Analyses
B. Paperwork Reduction Act
C. Federalism (E.O. 13132)
D. Customer Service (E.O. 14058)
E. Energy Impact Analysis (E.O. 13211)
F. Environmental Analysis
I. Executive Summary
A. Purpose of This Rulemaking
This rule is part of an incremental, multi-phased rulemaking that will culminate in the promulgation of comprehensive requirements that enable States to issue mobile driver's licenses and mobile identification cards (collectively “mDLs”) that comply with the REAL ID Act of 2005 (“REAL ID Act” or “Act”) and regulations [hereinafter “REAL ID-Compliant”]. In this first phase, the Transportation Security Administration (TSA) is making two changes to the current regulations in 6 CFR part 37, “REAL ID Driver's Licenses and Identification Cards.” First, TSA is adding definitions for, among others, mobile driver's licenses and mobile identification cards. These definitions provide a precise explanation of those terms as referenced in the REAL ID Act, which applies to only State-issued driver's licenses and State-issued identification cards. Any other types of identification cards, such as those issued by a Federal agency, or commercial, educational, or non-profit entity, are beyond the scope of the REAL ID Act and regulations, and hence this rulemaking, because they do not meet the definition of driver's license or identification card as defined by the REAL ID Act. The definition of “mDL” as used in this rulemaking is limited strictly to the REAL ID Act and regulations and does not include “mDLs” as defined by other entities.
The REAL ID Act of 2005, Division B Title II of the FY05 Emergency Supplemental Appropriations Act, as amended, Public Law 109-13, 119 Stat. 302 (May 11, 2005) (codified at 49 U.S.C. 30301 note) [hereinafter “REAL ID Act”]; 6 CFR part 37. Effective May 22, 2023, authority to administer the REAL ID program was delegated from the Secretary of Homeland Security to the Administrator of TSA pursuant to DHS Delegation No. 7060.2.1.
See sec. 201 of the REAL ID Act (defining a “driver's license” to include “driver's licenses stored or accessed via electronic means, such as mobile or digital driver's licenses, which have been issued in accordance with regulations prescribed by the Secretary”; mirroring definition for “identification card”).
Second, TSA is establishing a temporary waiver process that permits Federal agencies to accept mDLs for official purposes, as defined in the REAL ID Act and regulations, on an interim basis when full enforcement begins on May 7, 2025, but only if TSA has issued a waiver to the State. To qualify for the waiver, this final rule requires States to (1) be in full compliance with all applicable REAL ID requirements as defined in subpart E of this part, and (2) submit an application demonstrating that they meet the requirements specified in this rule, which are drawn from 19 industry standards and government guidelines. The rulemaking incorporates by reference (IBRs) those standards and guidelines, which cover technical areas such as mDL communication, digital identity, encryption, cybersecurity, and network/information system security and privacy.
The REAL ID Act defines official purposes as including but not limited to accessing Federal facilities, boarding Federally regulated commercial aircraft, entering nuclear power plants, and any other purposes that the Secretary shall determine. See REAL ID Act. Notably, because the Secretary has not determined any other official purposes, the REAL ID Act and regulations do not apply to Federal acceptance of driver's licenses and identification cards for other purposes, such as applying for Federal benefits programs, submitting immigration documents, or other Federal programs.
DHS, Final Rule, Minimum Standards for Driver's Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes, 88 FR 14473 (Mar. 9, 2023); DHS Press Release, DHS Announces Extension of REAL ID Full Enforcement Deadline (Dec. 5, 2022), https://www.dhs.gov/news/2022/12/05/dhs-announces-extension-real-id-full-enforcement-deadline (last visited July 17, 2024).
As noted above, this final rule is part of an incremental rulemaking that temporarily permits Federal agencies to accept mDLs for official purposes until TSA issues a subsequent rule that would set comprehensive requirements for mDLs. TSA believes it is premature to issue such requirements before the May 7, 2025 deadline due to the need for emerging industry standards and government guidelines to be finalized.
See TSA, Notice of Proposed Rulemaking, Waiver for Mobile Driver's Licenses, 88 FR 60056, 60063-64 (Aug. 30, 2023) [hereinafter “NPRM”].
The need for this rulemaking arises from TSA's desire to accommodate and foster the rapid pace of mDL innovation, while ensuring the intent of the REAL ID Act and regulations are met. Secure driver's licenses and identification cards are a vital component of our national security framework. In the REAL ID Act, Congress acted to implement the 9/11 Commission's recommendation that the Federal Government “set standards for the issuance of sources of identification, such as driver's licenses.” Under the REAL ID Act and regulations, a Federal agency may not accept for any official purpose a State-issued driver's license or identification card, either physical or an mDL, that does not meet specified requirements, as detailed in the REAL ID regulations ( see Part II.A., below, for more discussion on these requirements).
This final rule will result in the development of mDLs with a higher level of security, privacy, and interoperability features necessary for Federal acceptance for official purposes. Because the current regulatory provisions do not include requirements that would enable States to issue REAL ID-compliant mDLs, several States are investing significant resources to develop mDLs based on varying and often proprietary standards, many of which may lack security and privacy safeguards commensurate with REAL ID requirements and the privacy needs of users. Without timely regulatory guidance concerning potential requirements for developing a REAL ID-compliant mDL, States risk investing in mDLs that are not aligned with emerging industry standards and government guidelines that may be IBR'd in a future rulemaking. States, therefore, may become locked-in to existing solutions and could face a substantial burden to redevelop products acceptable to Federal agencies under this future rulemaking.
This final rule addresses these concerns by enabling TSA to grant a temporary waiver to States whose mDLs TSA determines provide sufficient safeguards for security and privacy, pending finalization of emerging standards. Although this rule does not set standards for the issuance of REAL ID-compliant mDLs, it does establish minimum requirements that States must meet to be granted a waiver so that mDLs can be accepted by Federal agencies for official purposes. These minimum standards and requirements ensure that States' investments in mDLs provide minimum privacy and security safeguards consistent with information currently known to the TSA.
B. Summary of the Major Provisions
As further discussed in Part II.A., below, mDLs cannot be accepted by Federal agencies for official purposes when REAL ID full enforcement begins on May 7, 2025, unless 6 CFR part 37 is amended to address mDLs. This final rule establishes a process for waiving, on a temporary and State-by-State basis, the current prohibition on Federal acceptance of mDLs for official purposes, and enables Federal agencies to accept mDLs on an interim basis while the industry matures to a point sufficient to enable TSA to develop more comprehensive mDL regulatory requirements.
The current regulations prohibit Federal agencies from accepting non-compliant driver's licenses and identification cards, including both physical cards and mDLs, when REAL ID enforcement begins on May 7, 2025. Any modification of this regulatory provision must occur through rulemaking (or legislation). Until and unless TSA promulgates comprehensive mDL regulations that enable States to issue REAL ID-compliant mDLs, mDLs cannot be developed to comply with REAL ID, and Federal agencies therefore cannot accept mDLs for official purposes after REAL ID enforcement begins on May 7, 2025. The rule allows the Federal government to accept mDLs on an interim basis, but only if TSA has issued a waiver to such State based on that State's compliance with all applicable REAL ID requirements as defined in subpart E of this part, and with the minimum privacy, safety, and interoperability requirements in this rulemaking. Please see Part II.A., below, for an explanation of the REAL ID requirement that both cards and issuing States must be REAL ID compliant.
C. Need for a Multi-Phased Rulemaking
TSA recognizes both that regulations can influence long-term industry research and investment decisions, and that premature regulations can distort the choices of technologies, which could harm competition and innovation. As noted above, there are clear reasons for TSA to issue requirements for mDLs in the context of REAL ID. Simultaneously, however, TSA observes that this is a rapidly innovating market, with multiple industry and government standards and guidelines necessary to ensure mDL privacy and security still in development. Accordingly, TSA has concluded that it is premature to promulgate comprehensive requirements for mDLs while key standards are being finalized because of the risk of unintended consequences, such as chilling innovation and competition in the marketplace, and “locking-in” stakeholders to certain technologies. TSA is therefore establishing a temporary waiver process with clear standards and requirements to facilitate the acceptance of mDLs while the industry matures and moves to accepted standards.
See NPRM, 88 FR at 60062-66.
TSA is proceeding with a multi-phased rulemaking approach. This “Phase 1” rule establishes a temporary waiver process that enables continuing Federal acceptance of mDLs for official purposes when REAL ID enforcement begins on May 7, 2025, and affords Federal agencies additional operational experience and data that would inform comprehensive regulations in the upcoming “Phase 2” rulemaking. The Phase 1 rule is intended to serve as a regulatory bridge until the emerging standards are finalized and a comprehensive Phase 2 rulemaking is effective.
TSA anticipates the future Phase 2 rulemaking would repeal the temporary waiver provisions established in Phase 1 and establish comprehensive requirements enabling States to issue mDLs that comply with REAL ID requirements. TSA envisions the Phase 2 rulemaking would draw heavily from pertinent parts of the emerging standards (pending review of those final, published documents) to set specific requirements for security, privacy, and interoperability. In addition, the Phase 2 rule would distinguish between existing regulatory requirements that apply only to mDLs versus physical cards. As one commenter to a previously-issued Request for Information (RFI) urged (discussed in Part II.B., below), DHS is taking “a slow and careful approach” to regulation in order to fully understand the implications of mDLs.
See comment from Electronic Privacy Information Center, https://downloads.regulations.gov/DHS-2020-0028-0048/attachment_1.pdf (last visited July 17, 2024); DHS, Request for Information, Mobile Driver's Licenses, 86 FR 20320 (Apr. 19, 2021).
This multi-phased rulemaking approach supports Executive Order (E.O.) 14058 of December 13, 2021 (Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government), by using “technology to modernize Government and implement services that are simple to use, accessible, equitable, protective, transparent, and responsive for all people of the United States.” As highlighted above and discussed in more detail below, allowing acceptance of mDLs issued by States that meet the waiver requirements enables the public to more immediately realize potential benefits of mDLs, including greater convenience, security, and privacy.
See86 FR 71357 (Dec. 16, 2021).
D. Costs and Benefits
TSA estimates the 10-year total cost of the rule to be $829.8 million undiscounted, $698.1 million discounted at 3 percent ($81.8 million annualized), and $563.9 million discounted at 7 percent ($80.3 million annualized). Affected entities include States, TSA, and relying parties (Federal agencies that voluntarily choose to accept mDLs for official purposes).
States incur costs to familiarize themselves with the requirements of the final rule, purchase access to an industry standard, submit an mDL waiver application, submit mDL waiver reapplications, and comply with waiver application requirements. TSA estimates that 40 States will seek an mDL waiver over the next 10 years at a 10-year State cost of $813.1 million undiscounted, $683.7 million discounted at 3 percent, and $552.0 million discounted at 7 percent.
TSA incurs costs associated with purchasing access to industry standards, reviewing mDL waiver applications and mDL waiver reapplications, acquiring, installing, and operating mDL readers, and training transportation security officers. TSA estimates the 10-year cost to TSA is $10.13 million undiscounted, $8.87 million discounted at 3 percent, and $7.56 million discounted at 7 percent.
Relying parties will incur costs to procure mDL readers should they voluntarily choose to accept mDLs for official purposes. TSA estimates the 10-year cost to relying parties is $6.57 million undiscounted, $5.48 million discounted at 3 percent, and $4.38 million discounted at 7 percent.
TSA also identifies other non-quantified costs that affected parties may incur. States may incur incremental costs to: monitor and study mDL technology as it evolves; resolve underlying issues that could lead to a suspension or termination of an mDL waiver; report serious threats to security, privacy, or data integrity; report material changes to mDL issuance processes; remove conflicts of interest with an independent auditor; and request reconsideration of a denied mDL waiver application. TSA may incur costs to: investigate circumstances that could lead to suspension or termination of a State's mDL waiver; provide notice to States, relying parties, and the public related to mDL waiver suspensions or terminations; develop an IT solution that maintains an up-to-date list of States with valid mDL waivers; develop materials related to process changes to adapt to mDL systems; and resolve requests for reconsideration of a denied mDL waiver application. An mDL user may incur costs with additional application requirements to obtain an mDL. States may also pass on mDL related costs to the public. Relying parties may incur costs to resolve any security or privacy issue with the mDL reader; report serious threats to security, privacy, or data integrity; verify the list of States with valid mDL waivers; train personnel to verify mDLs; and update the public on identification policies.
TSA does not possess data to quantify how States may implement a pass through or recoup costs associated with implementation of mDLs.
The final rule provides benefits to affected parties which include, but are not limited to: promoting higher security, privacy, and interoperability safeguards; reducing uncertainty in the mDL technology environment by helping to foster a minimum level of security, privacy and interoperability; and allowing Federal agencies to continue to accept mDLs for official purposes when REAL ID enforcement begins. Also, mDLs themselves may provide additional security benefits by offering a more secure verification of an individual's identity and authentication of an individual's credential compared to usage of physical cards.
II. Background
A. REAL ID Act, Regulations, and Applicability to mDLs
This rulemaking is authorized by the REAL ID Act of 2005 and REAL ID Modernization Act. The REAL ID Act authorizes the Secretary of Homeland Security, in consultation with the States and the Secretary of Transportation, to promulgate regulations to implement the requirements under the REAL Act. The REAL ID Modernization Act amended the definitions of “driver's license” and “identification card” to specifically include mDLs that have been issued in accordance with regulations prescribed by the Secretary of Homeland Security.
Sec. 205 of the REAL ID Act.
Sec. 1001 of the REAL ID Modernization Act, Title X of Division U of the Consolidated Appropriations Act, 2021, Public Law 116-260, 134 Stat. 2304 [hereinafter “REAL ID Modernization Act”].
The REAL ID Act and implementing regulations, 6 CFR part 37, set minimum requirements for State-issued driver's licenses and identification cards accepted by Federal agencies for official purposes, including accessing Federal facilities, boarding Federally regulated commercial aircraft, entering nuclear power plants, and any other purposes that the Secretary shall determine. The Act defines “driver's licenses” and “identification cards” strictly as State-issued documents, and the regulations further refine the definition of “identification card” as “a document made or issued by or under the authority of a State Department of Motor Vehicles or State office with equivalent function.” The REAL ID Act and regulations do not apply to identification cards that are not made or issued under a State authority, such as cards issued by a Federal agency or any commercial, educational, or non-profit entity.
REAL ID Act; 6 CFR part 37.
Sec. 201 of the REAL ID Act.
The regulations include a schedule describing when individuals must obtain a REAL ID-compliant driver's license or identification card intended for use for official purposes, known as “card-based” enforcement. Card-based enforcement begins on May 7, 2025. On this date, Federal agencies will be prohibited from accepting a State- or territory-issued driver's license or identification card for official purposes unless the card is compliant with the REAL ID Act and regulations.
See6 CFR 37.5(b). The regulations also include a schedule for State-based compliance, known as “State-based enforcement.” See6 CFR 37.51(a).
See6 CFR 37.5(b).
See6 CFR 37.5(b). Additionally, TSA is conducting a separate rulemaking that would allow Federal agencies to implement the card-based enforcement provisions of the REAL ID regulations under a phased approach beginning on the May 7, 2025 enforcement deadline. See NPRM, Phased Approach for Card-Based Enforcement, 89 FR 74137 (Sept. 12, 2024).
On December 21, 2020, Congress passed the REAL ID Modernization Act, which amended the REAL ID Act to update the definitions of “driver's license” and “identification card” to specifically include mDLs that have been issued in accordance with regulations prescribed by the Secretary, among other updates. Accordingly, mDLs must be REAL ID-compliant to be accepted by Federal agencies for official purposes when card-based enforcement begins on May 7, 2025. However, States cannot issue REAL ID-compliant mDLs until the regulations are updated to include requirements to ensure that mDLs meet equivalent levels of security currently imposed on REAL ID-compliant physical cards.
REAL ID Modernization Act, 134 Stat. 2304.
Sec. 1001 of the REAL ID Modernization Act, 134 Stat. 2304.
B. Rulemaking History
In April 2021, DHS issued an RFI announcing DHS's intent to commence future rulemaking to set the minimum technical requirements and security standards for mDLs to enable Federal agencies to accept mDLs for official purposes. The RFI requested comments and information to inform DHS's rulemaking. In response, DHS received 63 comments through a twice-extended comment period of 180 days, which closed on October 18, 2021.
86 FR 20320 (Apr. 19, 2021).
The 63 total comments included three duplicates and one confidential submission.
In August 2023, TSA published a Notice of Proposed Rulemaking (NPRM) drawing on comments to the RFI, which are summarized at 88 FR 60056, 60071-72. The NPRM comment period closed on October 16, 2023, and TSA received 31 comments. NPRM comments are discussed in detail in Part IV, below.
C. mDL Overview
1. mDLs Generally
An mDL is generally recognized as the digital representation of an individual's identity information contained on a State-issued physical driver's license or identification card. An mDL may be stored on a diverse range of portable or mobile electronic devices, such as smartphones, smartwatches, and storage devices containing memory. Like a physical card, mDL data originates from identity information about an individual that is maintained in the database of a State driver's licensing agency. An mDL has potential benefits for all stakeholders. For Federal agencies, mDLs may provide security and efficiency enhancements compared to physical cards, because mDLs rely on digital security features that are immune to many vulnerabilities of physical security features. For individuals, mDLs may provide a more secure, convenient, privacy-enhancing, and “touchless” method of identity verification compared to physical IDs.
A technical description of mDLs as envisioned by the American Association of Motor Vehicle Administrators may be found at https://www.aamva.org/Mobile-Drivers-License/ (last visited July 17, 2024).
Unlike physical cards that employ physical security features to deter fraud and tampering, mDLs combat fraud through the use of digital security features that are not recognizable through human inspection, such as asymmetric cryptography/public key infrastructure (PKI). As discussed in the NPRM, asymmetric cryptography generates a pair of encryption “keys” to encrypt and decrypt protected data. One key, a “public key,” is distributed publicly, while the other key, a “private key,” is held by the State driver's licensing agency ( e.g., a Department of Motor Vehicles). When the driver's licensing agency issues an mDL to an individual, the agency uses its private key to digitally “sign” the mDL data. A Federal agency accepting an mDL validates the integrity of the mDL data by obtaining the State driver's licensing agency's public key to verify the digital signature. Private keys and digital signatures are elements of data encryption that protect against unauthorized access, tampering, and fraud. Generally, mDL-based identity verification under REAL ID involves a triad of secure communications between a State driver's licensing agency, an mDL holder, and a Federal agency. Standardized communication interfaces are necessary to enable Federal agencies to exchange information with all U.S. States and territories that issue mDLs. Please see the NPRM for a more detailed discussion.
In contrast to physical driver's licenses that are read and verified visually through human inspection of physical security features, an mDL is read and verified electronically using a device known simply as a “reader. Any Federal agency that accepts mDLs for official purposes must use readers to validate an mDL holder's identity data from their mobile device and establish trust that the mDL is secure by using private-public key data encryption. An mDL reader compliant with this requirement can take multiple forms, such as an app installed on a mobile device, or a dedicated device. Although reader development is evolving, some companies already offer reader apps for free, and TSA therefore expects readers will be offered in a wide range capabilities and associated price points.
Non-Federal agencies and other entities who choose to accept mDLs for uses beyond the scope of REAL ID should also recognize the need for a reader to ensure the validity of the mDL. Any verifying entity can validate in the same manner as a Federal agency if they implement the standardized communication interface requirements specified in this final rule, which would require investment to develop the necessary IT infrastructure and related processes.
Readers for mDLs have specific requirements and at this time are not interchangeable with readers for other types of Federal cards, such as the Transportation Worker Identification Credential (TWIC). Although TSA is evaluating some mDLs at select airport security checkpoints, cost estimates for readers used in the evaluations are not available because those readers are non-commercially available prototypes designed specifically for integration into TSA-specific IT infrastructure that few, if any, other Federal agencies use. In addition, mDL readers are evolving and entities who accept mDLs would participate voluntarily. Accordingly, associated reader costs are not quantified at this time but TSA intends to gain a greater understanding of any costs to procure reader equipment as the technology continues to evolve.
2. State mDL Issuance and TSA Testing
As noted above, mDL issuance is proliferating rapidly among States, with at least half of all States believed to be preparing for or issuing mDLs. Although detailed mDL adoption statistics are unavailable, anecdotal information and media reports indicates that mDLs are rapidly gaining public acceptance. For example, Maryland commented that it has issued more than 200,000 mDLs to residents following a pilot in 2017 and more recent expansion in 2022 and 2023. Iowa commented that in the 3 months since it began offering its mDL app, it has been downloaded by more than 7,000 users.
See, e.g., AAMVA, Driver and Vehicle Services Data Map, https://www.aamva.org/jurisdiction-data-maps#anchorformdlmap (last visited July 17, 2024); PYMNTS, States Embrace Mobile Driver's Licenses to Fight Fraud Amid Privacy Scrutiny (Apr. 9, 2024), https://www.pymnts.com/identity/2024/states-embrace-mobile-drivers-licenses-to-fight-fraud-amid-privacy-scrutiny/ (last visited July 17, 2024); Government Technology, Digital IDs Are Here, but Where Are They Used and Accepted? (Mar. 12, 2024), https://www.govtech.com/biz/data/digital-ids-are-here-but-where-are-they-used-and-accepted (last visited July 17, 2024).
Comment by Maryland MVA, https://www.regulations.gov/comment/TSA-2023-0002-0032 (last visited July 17, 2024).
Comment by Iowa Department of Transportation, https://www.regulations.gov/comment/TSA-2023-0002-0023 (last visited July 17, 2024).
TSA understands that States are issuing mDLs using widely varying technology solutions, raising concerns whether such technological diversity provides the safeguards and interoperability necessary for Federal acceptance. Since 2022, TSA has been collaborating with States and industry to test the use of mDLs issued by participating States at select TSA airport security checkpoints. As of the date of this final rule, TSA is currently testing mDLs issued by 11 States (Arizona, California, Colorado, Georgia, Hawaii, Iowa, Louisiana, Maryland, New York, Ohio, Utah) at 27 airports.
See NPRM, 88 FR at 60066-67.
See TSA, Facial Recognition and Digital Identity Solutions, https://www.tsa.gov/digital-id (last visited Aug. 9, 2024).
D. Industry Standards and Government Guidelines for mDLs
The nascence of mDLs and absence of standardized mDL-specific requirements provide an opportunity for industry and government to develop standards and guidelines to close this void. TSA is aware of multiple such documents, published and under development, from both Federal and non-government sources. As discussed in Part III.C.8, below, this final rule amends § 37.4 by IBR'g into part 37 19 standards and guidelines that form the basis of many of the requirements in this final rule. TSA understands that these standards and guidelines discussed are the most comprehensive and relevant references governing mDLs today. TSA also acknowledges that many additional standards and guidelines are in development and may provide additional standardized mechanisms for mDLs.
See NPRM, 88 FR at 60063-66, for a discussion of these standards.
III. General Discussion of the Rulemaking
A. Changes Between NPRM and Final Rule
After carefully considering all comments received to the NPRM (see detailed discussion of comments and TSA's responses in Part IV, below), TSA finalizes the NPRM with several revisions in response to public comments. Table 1 summarizes the changes made in the final rule compared to the NPRM.
Table 1—Summary of Changes Between the NPRM and the Final Rule
Section | Final rule | Reason for the change |
---|---|---|
37.3 | Adds definition for “Provisioning.” | Technical change to add definition of a key term to improve clarity. |
37.4 | Revises points of contact for the public to contact TSA; provides additional means to access certain standards that are IBR'd in this rule | Technical changes to improve access to IBR materials. |
37.4(c)(1) | Corrects title of “Cybersecurity Incident & Vulnerability Response Playbooks” to “Federal Government Cybersecurity Incident & Vulnerability Response Playbooks.” | Technical correction. |
37.4(g)(4) | Updates standard NIST FIPS PUB 197 to NIST FIPS PUB 197-upd1 to reflect revised version of standard | Technical change to reflect revisions to standard to improve public access. Revisions include editorial improvements, but no technical changes to the algorithm specified in the earlier version. |
37.4(g)(7) | Corrects website address to the cited standard | Technical change to correct a typo. |
37.7(a) | Clarifies conditions under which TSA will issue a waiver | Clarification regarding impact of the waiver. |
37.7(b)(3) | Deleted | Deleted proposed language that would have made a State ineligible to apply for a waiver if the State issues mDLs to individuals with non-REAL ID compliant physical cards (in addition to issuing mDLs to other individuals that have compliant physical cards). |
37.8(c) | Adds paragraph (c) to require Federal agencies accepting mDLs to confirm, consistent with the deadlines set forth in § 37.5, that the mDL data element “DHS_compliance” is encoded “F,” as required by §§ 37.10(a)(4)(ii) & (a)(1)(vii) | Clarifies that when REAL ID enforcement begins, Federal agencies may accept mDLs from States only if the underlying physical card is REAL ID compliant. |
37.8(d) | Renumbers § 37.8(c), as proposed in the NPRM, to § 37.8(d) in light of addition of new § 37.8(c) Corrects website address from dhs.gov to tsa.gov Adds requirement regarding protection of SSI | Technical changes renumber provision from 37.8(c) to 37.8(d), update agency name and website address, and clarify the mechanics of reporting. Provides that reports may contain sensitive security information (SSI) and if so, would be subject to requirements of 49 CFR part 1520. |
37.9(a) | Corrects agency name from DHS to TSA Corrects website address from dhs.gov to tsa.gov | Technical changes update agency name and website address. |
37.9(b) | Revises “days” to “calendar days.” Corrects website address from dhs.gov to tsa.gov | Clarifies that “days” means calendar days, not business days. Technical change updates agency website address. |
37.9(c) | Revises “days” to “calendar days.” Corrects website address from dhs.gov to tsa.gov | Clarifies that “days” means calendar days, not business days. Technical change updates agency website address. |
37.9(e)(2) | Revises “days” to “calendar days.” Corrects website address from dhs.gov to tsa.gov Provides a means for States to contact TSA if the State is unclear whether certain modifications to its mDL issuance processes require reporting | Clarifies that “days” means calendar days, not business days. Technical change updates agency website address. Provides a means for States to resolve potential questions regarding reporting requirements. |
37.9(e)(4)(ii) | Revises “days” to “calendar days.” | Clarifies that “days” means calendar days, not business days. |
37.9(e)(5)(i) | Corrects agency name from DHS to TSA | Technical change updates agency name. |
37.9(e)(5)(ii) | Revises “days” to “calendar days.” | Clarifies that “days” means calendar days, not business days. |
37.9(g) | Adds new paragraph (g), which provides that information submitted in response to requirements to apply for and maintain a waiver may contain SSI, and if so, would be subject to requirements of 49 CFR part 1520 | SSI protection. |
37.10(a)(1)(vii) | Replaces NPRM requirement that States must issue mDLs only to residents who have been issued physical cards that are valid, unexpired, and REAL ID-compliant with requirement that States must populate the “DHS_compliance” data field to correspond to the REAL ID-compliance status of the underlying physical driver's license or identification card, or as required by the AAMVA Guidelines | Proposed language would have required States to issue mDLs only to individuals to whom that State previously issued a physical card that is valid, unexpired, and REAL ID-compliant. This would have denied States the discretion to issue mDLs to holders of non-compliant physical cards. Revisions require States to issue mDLs in a manner that reflects the REAL ID compliance status of the underlying physical card. This is consistent with the intent of the NPRM, which was to enable Federal agencies to determine the REAL ID-compliance status of the underlying physical card, and accept only compliant cards when enforcement begins. |
37.10(a)(4) | Corrects version number of AAMVA Mobile Driver's License (mDL) Implementation Guidelines (Jan. 2023) Updates NIST FIPS PUB 197 to NIST FIPS PUB 197-upd1 to reflect revised version of standard | Technical change corrects version number of AAMVA Guidelines. Changes reflect current version of NIST FIPS PUB 197 to ensure continuing public access. Revisions to the standard include editorial improvements, but no technical changes to the algorithm specified in the earlier version. |
37.10(b)(1) | Clarifies that “independent entity” includes State employees or contractors that are independent of the State's driver's licensing agency | Provides States additional options to select auditors. Reduces burdens without impact on security or privacy. |
37.10(c) | Corrects website address from dhs.gov to tsa.gov Clarifies that TSA will publish in the Federal Register a notice advising of the availability of updated TSA mDL Waiver Application Guidance, which itself will be published at www.tsa.gov/mDL/ | Technical changes update agency website address, and clarify means of notifying and publishing updates to TSA mDL Waiver Application Guidance. |
Appendix A, Throughout | Corrections to titles of: CISA Federal Government Cybersecurity Incident & Vulnerability Response Playbooks DHS National Cyber Incident Response Plan NIST FIPS PUB 140-3 NIST Framework for Improving Critical Infrastructure Cybersecurity | Technical corrections. |
Appendix A, paragraph 1.1 | Adds section numbers to certain references Deletes requirement to comply with NIST SP 800-53B | Technical changes clarify which parts of cited reference require compliance, and remove an unnecessary requirement. |
Appendix A, paragraph 2.2 | Revises “privileged account or service” in NPRM to “trusted role.” | Technical change corrects terminology. |
Appendix A, paragraph 2.13 | Adds section numbers to a certain reference | Technical change clarifies which parts of cited reference require compliance. |
Appendix A, paragraph 5.13 | Reduces requirements for minimum number of personnel to generate issuing authority certificate authority (IACA) root certificate keys from a minimum of three to two persons, consisting of at least one ceremony administrator and one qualified witness | Provides States greater freedom to select products. Does not impact security, privacy, or interoperability. |
Appendix A, paragraph 5.14 | Modifies requirements for minimum number of personnel to generate document signer keys. Final rule requires either at least one administrator and one qualified witness (other than a person involved in key generation), or at least 2 administrators using split knowledge processes | Provides States greater freedom to select products. Does not impact security, privacy, or interoperability. |
Appendix A, paragraph 6.3 | Revises “days” to “calendar days | Clarifies that “days” means calendar days, not business days. |
Appendix A, paragraph 8.6 | Modifies cyber incident reporting requirements to incidents as defined in the TSA Cybersecurity Lexicon available at www.tsa.gov that may harm state certificate systems Corrects website address from dhs.gov to tsa.gov Adds SSI protection requirements | Clarifies types of incidents that must be reported, updates agency website address, and adds SSI protection. |
SSI is information obtained or developed in the conduct of security activities, the disclosure of which would constitute an unwarranted invasion of privacy, reveal trade secrets or privileged or confidential information, or be detrimental to the security of transportation. The protection of SSI is governed by 49 CFR part 1520.
Table 2—Total Cost of the Rule by Entity
[$ Thousands]
Year | States cost | TSA cost | Relying party cost | Total rule cost | ||
---|---|---|---|---|---|---|
a | b | c | d = a + b + c | |||
Undiscounted | Discounted at 3% | Discounted at 7% | ||||
1 | $42,876 | $1,595 | $79 | $44,551 | $43,253 | $41,636 |
2 | 62,791 | 1,715 | 919 | 65,424 | 61,669 | 57,144 |
3 | 71,352 | 1,209 | 537 | 73,098 | 66,895 | 59,670 |
4 | 83,182 | 1,102 | 381 | 84,665 | 75,224 | 64,591 |
5 | 94,460 | 864 | 375 | 95,699 | 82,551 | 68,232 |
6 | 91,467 | 695 | 1,160 | 93,323 | 78,156 | 62,185 |
7 | 91,881 | 727 | 742 | 93,351 | 75,903 | 58,134 |
8 | 91,743 | 730 | 558 | 93,031 | 73,440 | 54,145 |
9 | 91,467 | 719 | 531 | 92,717 | 71,060 | 50,432 |
10 | 91,881 | 774 | 1,289 | 93,944 | 69,903 | 47,757 |
Total | 813,102 | 10,128 | 6,573 | 829,803 | 698,054 | 563,925 |
Annualized | 81,833 | 80,290 | ||||
Note: Totals may not add due to rounding. |
Table 3—Total Cost of the Rule to States
[$ Thousands]
Year | Familiarization cost | Standards cost | Waiver application cost | Reapplication cost | Escalated review cost | Infrastructure security cost | Total cost to states | ||
---|---|---|---|---|---|---|---|---|---|
a | b | c | d | e | f | g = a + b + c + d + e + f | |||
Undiscounted | Discounted at 3% | Discounted at 7% | |||||||
1 | $63.3 | $1.9 | $592.1 | $0 | $7.2 | $42,212 | $42,876 | $41,628 | $40,071 |
2 | 0 | 1.3 | 394.7 | 0 | 12.0 | 62,383 | 62,791 | 59,186 | 54,844 |
3 | 0 | 0.6 | 197.4 | 0 | 14.4 | 71,140 | 71,352 | 65,297 | 58,244 |
4 | 0 | 0.6 | 197.4 | 413.9 | 16.8 | 82,553 | 83,182 | 73,906 | 63,459 |
5 | 0 | 0.6 | 197.4 | 275.9 | 19.2 | 93,967 | 94,460 | 81,482 | 67,349 |
6 | 0 | 0 | 0 | 138.0 | 19.2 | 91,310 | 91,467 | 76,603 | 60,949 |
7 | 0 | 0 | 0 | 551.8 | 19.2 | 91,310 | 91,881 | 74,708 | 57,219 |
8 | 0 | 0 | 0 | 413.9 | 19.2 | 91,310 | 91,743 | 72,423 | 53,395 |
9 | 0 | 0 | 0 | 138.0 | 19.2 | 91,310 | 91,467 | 70,102 | 49,752 |
10 | 0 | 0 | 0 | 551.8 | 19.2 | 91,310 | 91,881 | 68,368 | 46,708 |
Total | 63.3 | 5.0 | 1,578.9 | 2,483.2 | 165.2 | 808,807 | 813,102 | 683,704 | 551,991 |
Annualized | 80,151 | 78,591 | |||||||
Note: Totals may not add due to rounding. |
Table 4—Total Cost of the Rule to TSA ($ Thousands)
Year | Standards cost | Application review cost | Reapplication review cost | mDL reader cost | mDL training cost | Total cost to TSA | ||
---|---|---|---|---|---|---|---|---|
a | b | c | d | e | f = a + b + c + d + e | |||
Undiscounted | Discounted at 3% | Discounted at 7% | ||||||
1 | $0.4 | $74.3 | $0 | $1,418.8 | $101.5 | $1,595.0 | $1,548.5 | $1,490.6 |
2 | 0 | 49.5 | 0 | 699.8 | 965.4 | 1,714.7 | 1,616.3 | 1,497.7 |
3 | 0 | 24.8 | 0 | 547.9 | 636.2 | 1,208.9 | 1,106.4 | 986.9 |
4 | 0 | 24.8 | 39.9 | 440.6 | 596.4 | 1,101.8 | 978.9 | 840.5 |
5 | 0 | 24.8 | 26.6 | 240.6 | 571.7 | 863.7 | 745.0 | 615.8 |
6 | 0 | 0.0 | 13.3 | 199.4 | 482.0 | 694.7 | 581.8 | 462.9 |
7 | 0 | 0.0 | 53.2 | 200.9 | 473.3 | 727.5 | 591.5 | 453.0 |
8 | 0 | 0.0 | 39.9 | 202.3 | 487.4 | 729.7 | 576.0 | 424.7 |
9 | 0 | 0.0 | 13.3 | 203.8 | 501.4 | 718.5 | 550.7 | 390.8 |
10 | 0 | 0.0 | 53.2 | 205.2 | 515.5 | 773.9 | 575.9 | 393.4 |
Total | 0.4 | 198.2 | 239.6 | 4,359.4 | 5,330.8 | 10,128.4 | 8,870.9 | 7,556.4 |
Annualized | 1,039.9 | 1,075.9 | ||||||
Note: Totals may not add due to rounding. |
Table 5—Total Cost of the Rule to Relying Parties ($ Thousands)
79Year | mDL reader cost | Total cost to relying parties | ||
---|---|---|---|---|
a | b = a | |||
Undiscounted | Discounted at 3% | Discounted at 7% | ||
1 | $79.3 | $79.3 | $76.9 | $74.1 |
2 | 918.8 | 918.8 | 866.0 | 802.5 |
3 | 537.4 | 537.4 | 491.8 | 438.7 |
4 | 381.3 | 381.3 | 338.8 | 290.9 |
5 | 375.0 | 375.0 | 323.5 | 267.4 |
6 | 1,160.4 | 1,160.4 | 971.9 | 773.3 |
7 | 741.8 | 741.8 | 603.1 | 461.9 |
8 | 558.3 | 558.3 | 440.7 | 324.9 |
9 | 531.2 | 531.2 | 407.1 | 288.9 |
10 | 1,289.1 | 1,289.1 | 959.2 | 655.3 |
Total | 6,572.6 | 6,572.6 | 5,479.1 | 4,377.9 |
Annualized | 642.3 | 623.3 | ||
Note: Totals may not add due to rounding. |
Table 6—OMB A-4 Accounting Statement
[$ Millions, 2022 dollars]
Category | Estimates | Units | Notes | ||||
---|---|---|---|---|---|---|---|
Primary estimate | Low estimate | High estimate | Year dollar | Discount rate % | Period covered | ||
Benefits: | |||||||
Annualized Monetized ($ millions/year) | N/A | N/A | N/A | N/A | 7 | N/A | Not quantified. |
N/A | N/A | N/A | N/A | 3 | N/A | ||
Annualized Quantified | N/A | N/A | N/A | N/A | 7 | N/A | Not quantified. |
N/A | N/A | N/A | N/A | 3 | N/A | ||
Qualitative | The rule will produce benefits by reducing uncertainty in the mDL technology environment by helping to foster a minimum level of security, privacy and interoperability, and reduce potential costs through the alignment of development activities across disparate efforts. | ||||||
Costs: | |||||||
Annualized Monetized ($ millions/year) | $80.29 | N/A | N/A | 2022 | 7 | 10 years | NPRM Regulatory Impact Analysis (RIA). |
$81.83 | N/A | N/A | 2022 | 3 | 10 years | ||
Annualized Quantified | N/A | N/A | N/A | N/A | 7 | N/A | Not quantified. |
N/A | N/A | N/A | N/A | 3 | N/A | ||
Qualitative | States may incur incremental costs to: monitor and study mDL technology as it evolves; resolve the underlying issues that could lead to a suspension or termination of an mDL waiver; report serious threats to security, privacy, or data integrity; report material changes to mDL issuance processes; remove conflicts of interest with an independent auditor; and request reconsideration of a denied mDL waiver application. TSA may incur costs to: investigate circumstances that could lead to suspension or termination of a State's mDL waiver; provide notice to States, relying parties, and the public related to mDL waiver suspensions or terminations; develop an IT solution that maintains an up-to-date list of States with valid mDL waivers; develop materials related to the process changes to adapt to mDL systems; and resolve a request for reconsideration of a denied mDL waiver application. An mDL user may incur costs with additional application requirements to obtain an mDL. Relying parties may incur costs to resolve any security or privacy issue with the mDL reader; report serious threats to security, privacy, or data integrity; verifying the list of States with valid mDL waivers; train personnel to verify mDLs; and update the public on identification policies. | ||||||
Transfers: | |||||||
From/To | From: | N/A | To: | N/A | |||
States may pass on costs associated with mDLs and the final rule to the public. | |||||||
Effects On: | |||||||
State, Local, and/or Tribal Government: The final rule will result in States incurring 552.0 million discounted at 7 percent | |||||||
Small Business: None | NPRM Regulatory Flexibility Analysis (RFA). | ||||||
Wages: None | |||||||
Growth: Not measured |
Table 7—PRA Information Collection Responses and Burden Hours
Collection activity | Number of responses | Total hours | Average annual hours | |||||
---|---|---|---|---|---|---|---|---|
Year 1 | Year 2 | Year 3 | Total responses | Average annual responses | Time per response (hours) | |||
d = a + b + c | e = d/3 | f | g = d * f | h = g/3 | ||||
mDL Waiver Application | 15.0 | 10.0 | 5.0 | 30.0 | 10.0 | 20 | 600 | 200 |
mDL Waiver Resubmission | 13.5 | 9.0 | 4.5 | 27.0 | 9.0 | 5 | 135 | 45 |
mDL Waiver Reapplication | 0 | 0 | 0 | 0 | 0 | 15 | 0 | 0 |
Total | 28.5 | 19.0 | 9.5 | 57.0 | 19.0 | 735 | 245 |
Paragraph | Requirement |
---|---|
1: Certificate Authority Certificate Life-Cycle Policy | |
1.1 | Maintain a certificate policy, which forms the State's certificate system governance framework. If certificate systems are managed at a facility not controlled by the State, the State must require any delegated third party to comply with the State's certificate policy. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Sections 2, 4.3, 4.9, 5, 6, as applicable; | |
• ISO/IEC 18013-5:2021(E), Annex B; | |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST SP 800-57 Part 1, Rev. 5, Sections 3, 5, 6, 7, 8; | |
• NIST SP 800-57 Part 2, Rev. 1; | |
• NIST SP 800-57 Part 3, Rev. 1, Sections 2, 3, 4, 8, 9; | |
• NIST 800-53 Rev. 5, AC-1, AT-1, AU-1, CA-1, CM-1, CP-1, IA-1, IR-1, MA-1, MP-1, PE-1, PL-1, PL-2, PL-8, PL-10, PM-1, PS-1, PT-1, RA-1, SA-1, SC-1, SI-1, and SR-1. | |
1.2 | Perform management and maintenance processes which includes baseline configurations, documentation, approval, and review of changes to certificate systems, issuing systems, certificate management systems, security support systems, and front end and internal support systems. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.IP-3; and | |
• NIST SP 800-53 Rev. 5, CM-1, CM-2, CM-3, CM-4, CM-5, CM-6, CM-8, CM-9, CM-10, CM-11, CM-12, MA-2, MA-3, MA-4, MA-5, MA-6, PE-16, PE-17, PE-18, PL-10, PL-11, RA-7, SA-2, SA-3, SA-4, SA-5, SA-8, SA-9, SA-10, SA-11, SA-15, SA-17, SA-22, SC-18, SI-6, SI-7, SR-2, SR-5. | |
1.3 | Apply recommended security patches, to certificate systems within six months of the security patch's availability, unless the State documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity ID.RA-1, PR.IP-12; and | |
• NIST SP 800-53 Rev. 5, SI-2, SI-3. | |
2: Certificate Authority Access Management | |
2.1 | Grant administration access to certificate systems only to persons acting in trusted roles, and require their accountability for the certificate system's security, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-4; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-3, AC-5, AC-6, AC-8, AC-21, AC-22, AC-24, CA-6, PS-6. | |
2.2 | Change authentication keys and passwords for any trusted role account on a certificate system whenever a person's authorization to administratively access that account on the certificate system is changed or revoked, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-1; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-3, AC-6, IA-1, IA-2, PS-4, PS-5. | |
2.3 | Follow a documented procedure for appointing individuals to trusted roles and assigning responsibilities to them, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-1; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-3, AC-5, AC-6, IA-1, IA-2. | |
2.4 | Document the responsibilities and tasks assigned to trusted roles and implement “separation of duties” for such trusted roles based on the security-related concerns of the functions to be performed, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity—PR.AC-4; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-5, AC-6, MP-2, PS-9. | |
2.5 | Restrict access to secure zones and high security zones to only individuals assigned to trusted roles, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-3, AC-5, AC-6, MP-2, PS-1, PS-6. | |
2.6 | Restrict individuals assigned to trusted roles from acting beyond the scope of such role when performing administrative tasks assigned to that role, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-1, PR.AC-4, PR.AC-6, PR.AT-2; and | |
• NIST SP 800-53 Rev. 5, AT-2, AT-3, PM-13, PM-14. | |
2.7 | Require employees and contractors to observe the principle of “least privilege” when accessing or configuring access privileges on certificate systems, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-4, PR.AC-2; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, AC-3, AC-5, AC-6, PE-1, PE-3, PL-4. | |
2.8 | Require that individuals assigned to trusted roles use a unique credential created by or assigned to them in order to authenticate to certificate systems, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-1, PR.AC-6, PR.AC-4, PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-1, IA-1, IA-2, IA-3, IA-5, IA-8, IA-12. | |
2.9 | Lockout account access to certificate systems after a maximum of five failed access attempts, provided that this security measure: |
1. Is supported by the certificate system; | |
2. Cannot be leveraged for a denial-of-service attack; and | |
3. Does not weaken the security of this authentication control. | |
These requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-7. | |
2.10 | Implement controls that disable all privileged access of an individual to certificate systems within 4 hours of termination of the individual's employment or contracting relationship with the State or Delegated Third Party, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-1, AC-2, PS-1, PS-4, PS-7. | |
2.11 | Implement multi-factor authentication or multi-party authentication for administrator access to issuing systems and certificate management systems, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity-PR.AC-6, PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-14, IA-1, IA-2, IA-3, IA-5, IA-8, IA-11. | |
2.12 | Implement multi-factor authentication for all trusted role accounts on certificate systems, including those approving the issuance of a Certificate and delegated third parties, that are accessible from outside a secure zone or high security zone, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-17, AC-18, AC-19, AC-20, IA-1, IA-2, IA-3, IA-4, IA-5, IA-6, IA-8. | |
2.13 | If multi-factor authentication is used, implement only multi-factor authentication that achieves an Authenticator Assurance Level equivalent to AAL2 or higher, in full compliance with the following references: |
• NIST SP 800-63-3, Sections 4.3, 6.2; | |
• NIST SP 800-63B, Section 4.2; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, IA-5, IA-7. | |
2.14 | If multi-factor authentication is not possible, implement a password policy for trusted role accounts in full compliance with NIST SP 800-63B, Section 5.1.1.2, Memorized Secret Verifiers, and implement supplementary risk controls based on a system risk assessment. |
2.15 | Require trusted roles to log out of or lock workstations when no longer in use, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, AC-11, AC-12. | |
2.16 | Configure workstations with inactivity time-outs that log the user off or lock the workstation after a set time of inactivity without input from the user. A workstation may remain active and unattended if the workstation is otherwise secured and running administrative tasks that would be interrupted by an inactivity time-out or system lock. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, AC-11, AC-12. | |
2.17 | Review all system accounts at least every three months and deactivate any accounts that are no longer necessary for operations, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-1; and | |
• NIST SP 800-53 Rev. 5, AC-2. | |
2.18 | Restrict remote administration or access to a State issuing system, certificate management system, or security support system, including access to cloud environments, except when: |
1. The remote connection originates from a device owned or controlled by the State or delegated third party; | |
2. The remote connection is through a temporary, non-persistent encrypted channel that is supported by Multi-Factor Authentication; and | |
3. The remote connection is made to a designated intermediary device— | |
a. located within the State's network or secured Virtual Local Area Network (VLAN), | |
b. secured in accordance with the requirements of this Appendix, and | |
c. that mediates the remote connection to the issuing system. | |
These Requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-3, PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, AC-17, AC-19, AC-20, IA-3, IA-4, IA-6. | |
3: Facility, Management, and Operational Controls | |
3.1 | Restrict physical access authorizations at facilities where certificate systems reside, including facilities controlled by a delegated third party, by: |
1. Verifying individual access authorizations before granting access to the facility; | |
2. Controlling ingress and egress to the facility using appropriate security controls; | |
3. Controlling access to areas within the facility designated as publicly accessible; | |
4. Escorting visitors, logging visitor entrance and exit from facilities, and limiting visitor activities within facilities to minimize risks to certificate systems; | |
5. Securing physical keys, combinations, and other physical access devices; | |
6. Maintaining an inventory of physical keys, combinations, and physical access devices; conduct review of this inventory at least annually; and | |
7. Changing combinations and keys every three years or when physical keys are lost, combinations are compromised, or when individuals possessing the physical keys or combinations are transferred or terminated. | |
These requirements must be implemented in full compliance with the following reference: | |
• NIST SP 800-53 Rev. 5, PE-2, PE-3, PE-4, PE-5, PE-8. | |
3.2 | Implement controls to protect certificate system operations and facilities where certificate systems reside from environmental damage and/or physical breaches, including facilities controlled by a delegated third party, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, CP-2, CP-4, CP-6, CP-7, CP-8, CP-9, CP-10, PE-2, PE-9, PE-10, PE-11, PE-12, PE-13, PE-14, PE-15, PE-21. | |
3.3 | If certificate systems are managed at a facility not controlled by the State, implement controls to prevent risks to such facilities presented by foreign ownership, control, or influence, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, SR-2, SR-3, SR-4, SR-6. | |
3.4 | Implement controls to prevent supply chain risks for certificate systems including: |
1. Employing acquisition strategies, tools, and methods to mitigate risks; | |
2. Establishing agreements and procedures with entities involved in the supply chain of certificate systems; | |
3. Implementing an inspection and tamper protection program for certificate systems components; | |
4. Developing and implementing component authenticity policies and procedures; and | |
5. Developing and implementing policies and procedures for the secure disposal of certificate systems components. | |
These requirements must be implemented in full compliance with the following reference: | |
• NIST SP 800-53 Rev. 5, SR-5, SR-8, SR-9, SR-10, SR-11, SR-12. | |
4: Personnel Security Controls | |
4.1 | Implement and disseminate to personnel with access to certificate systems and facilities, including facilities controlled by a delegated third party, a policy to control insider threat security risks that: |
1. Addresses the purpose, scope, roles, responsibilities, management commitment, coordination among State entities, and compliance; | |
2. Complies with all applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and | |
3. Designates an official in a trusted role to manage the development, documentation, and dissemination of the policy and procedures. | |
These requirements must be implemented in full compliance with the following reference: | |
• NIST SP 800-53 Rev. 5, MA-5, PS-1, PS-8. | |
4.2 | Assign a risk designation to all organizational positions with access to certificate systems and facilities, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, PS-2, PS-9. | |
4.3 | Establish screening criteria for personnel filling organization positions with access to certificate system and facilities, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, PS-2, PS-3, SA-21. | |
4.4 | Screen individual personnel in organizational positions with access to certificate systems and facilities, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, PS-3. | |
4.5 | Upon termination of individual employment, State or delegated third party must: |
1. Disable system access within 4 hours; | |
2. Terminate or revoke any authenticators and credentials associated with the individual; | |
3. Conduct exit interviews that include— | |
a. Notifying terminated individuals of applicable, legally binding post-employment requirements for the protection of organizational information, and | |
b. Requiring terminated individuals to sign an acknowledgment of post-employment requirements as part of the organizational termination process; | |
4. Retrieve all security-related organizational system-related property; and | |
5. Retain access to organizational information and systems formerly controlled by terminated individual. | |
These requirements must be implemented in full compliance with the following reference: | |
• NIST SP 800-53 Rev. 5, PS-4. | |
4.6 | Review and update personnel security policy, procedures, and position risk designations at least once every 12 months, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, PS-1, PS-2. | |
4.7 | Provide training to all personnel performing certificate system duties, on the following topics: |
1. Fundamental principles of Public Key Infrastructure; | |
2. Authentication and vetting policies and procedures, including the State's certificate policy; | |
3. Common threats to certificate system processes, including phishing and other social engineering tactics; | |
4. Role specific technical functions related to the administration of certificate systems; and | |
5. The requirements of this Appendix. | |
These requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Section 5.3.3; and | |
• NIST SP 800-53 Rev. 5, CP-3, IR-2, SA-16. | |
4.8 | Maintain records of training as required by paragraph 4.7 of this Appendix, in full compliance with the following references: |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Sections 5.3.3, 5.4.1; and | |
• NIST SP 800-53 Rev. 5, AT-4. | |
4.9 | Implement policies and processes to prevent any delegated third party personnel managing certificate systems at a facility not controlled by a State from being subject to risks presented by foreign control or influence, in full compliance with the following reference: |
• NIST SP 800-53 Rev. 5, SR-3, SR-4, SR-6. | |
5: Technical Security Controls | |
5.1 | Segment certificate systems into networks based on their functional or logical relationship, such as separate physical networks or VLANs, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-5; and | |
• NIST SP 800-53 Rev. 5, AC-4, AC-10, CA-3, CA-9, MP-3, MP-4, RA-2, RA-9, SC-2, SC-3, SC-4, SC-8. | |
5.2 | Apply equivalent security controls to all systems co-located in the same network (including VLANs) with a certificate system, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-5; and | |
• NIST SP 800-53 Rev. 5, MP-5, MP-6, MP-7, RA-2, SC-7, SC-10, SC-39. | |
5.3 | Maintain State root certificate authority systems in a high security zone and in an offline state or air-gapped from all other network operations. If operated in a cloud environment, State root certificate authority systems must use a dedicated VLAN with the sole purpose of Issuing Authority Certificate Authority (IACA) root certificate functions and be in an offline state when not in use for IACA root certificate functions. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, SC-32. | |
5.4 | Protect IACA root certificate private keys using dedicated hardware security modules (HSMs), either managed on-premises or provided through cloud platforms, that are under sole control of the State or delegated third party. These requirements must be implemented in full compliance with the following references: |
• NIST SP 800-57 Part 1, Rev. 5; | |
• NIST FIPS PUB 140-3; and | |
• NIST SP 800-53 Rev. 5, SC-12, SC-13. | |
5.5 | Protect certificate systems private keys using NIST FIPS PUB 140-3 Level 3 or Level 4 certified HSMs, in full compliance with the following references: |
• NIST FIPS PUB 140-3; and | |
• NIST SP 800-53 Rev. 5, SC-12, SC-13. | |
5.6 | Protect document signer private keys using HSMs, either managed on-premises or provided through cloud platforms, that are under sole control of the State or delegated third party. These requirements must be implemented in full compliance with the following references: |
• NIST SP 800-57 Part 1, Rev. 5; | |
• NIST FIPS PUB 140-3; and | |
• NIST SP 800-53 Rev. 5, SC-12, SC-13. | |
5.7 | Protect certificate systems document signer keys using NIST FIPS PUB 140-3 Level 2, Level 3, or Level 4 certified HSMs, in full compliance with the following references: |
• NIST FIPS PUB 140-3; and | |
• NIST SP 800-53 Rev. 5, SC-12, SC-13. | |
5.8 | Maintain and protect issuing systems, certificate management systems, and security support systems in at least a secure zone, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, SC-15, SC-20, SC-21, SC-22, SC-24, SC-28, SI-16. | |
5.9 | Implement and configure: security support systems that protect systems and communications between systems inside secure zones and high security zones, and communications with non-certificate systems outside those zones (including those with organizational business units that do not provide PKI-related services) and those on public networks. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, SC-15, SC-20, SC-21, SC-22, SC-24, SC-28, SI-16. | |
5.10 | Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications that the State has identified as necessary to its operations. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, AC-4, SI-3, SI-8, SC-7, SC-10, SC-23, CM-7. | |
5.11 | Configure issuing systems, certificate management systems, security support systems, and front end and internal support systems by removing or disabling all accounts, applications, services, protocols, and ports that are not used in the State's or delegated third party's operations and restricting use of such systems to only those that are approved by the State or delegated third party. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.PT-3; and | |
• NIST SP 800-53 Rev. 5, CM-7. | |
5.12 | Implement multi-factor authentication on each component of the certificate system that supports multi-factor authentication, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.AC-7; and | |
• NIST SP 800-53 Rev. 5, IA-2. | |
5.13 | Generate IACA root certificate key pairs with a documented and auditable multi-party key ceremony, performing at least the following steps: |
1. Prepare and follow a key generation script; | |
2. Require a qualified person who is in a trusted role and not a participant in the key generation to serve as a live witness of the full process of generating the IACA root certificate key pair, or record a video in lieu of a live witness; | |
3. Require the qualified witness to issue a report confirming that the State followed its key ceremony during its key and certificate generation process, and confirming that controls were used to protect the integrity and confidentiality of the key pair; | |
4. Generate the IACA root certificate key pair in a physically secured environment as described in the State's certificate policy and/or certification practice statement; | |
5. Generate the IACA root certificate key pair using personnel in trusted roles under the principles of multiple person control and split knowledge. IACA root certificate key pair generation requires a minimum of two persons, consisting of at least one key generation ceremony administrator and one qualified witness); | |
6. Log the IACA root certificate key pair generation activities, sign the witness report (and video file, if applicable), with a document signing key which has been signed by the IACA root certificate private key, and include signed files and document signing public certificate with the IACA root certificate key pair generation log files; and | |
7. Implement controls to confirm that the IACA root certificate private key was generated and protected in conformance with the procedures described in the State's certificate policy and/or certification practice statement and the State's key generation script. These requirements must be implemented in full compliance with the following reference: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Section 6.1.1.1. | |
5.14 | Generate document signer key pairs with a documented and auditable multi-party key ceremony, performing at least the following steps: |
1. Prepare and follow a key generation script; | |
2. Generate the document signer key pairs in a physically secured environment as described in the State's certificate policy and/or certification practice statement; | |
3. Generate the document signer key pairs using only personnel in trusted roles under the principles of multiple person control and split knowledge. document signer key pair generation requires a, minimum of two persons, consisting of at least one key generation ceremony administrator and at least one qualified witness or at least two key generation ceremony administrators when split knowledge generation is in place; | |
4. If a witness observes the key generation, require a qualified person who is in a trusted role and not a participant in the key generation to serve as a live witness of the full process of generating the document signer key pair; and | |
5. Require the qualified witness to issue a report confirming that the State followed its key ceremony during its key and certificate generation process and confirming that controls were used to rotect the integrity and confidentiality of the key pair; | |
6. Log the document signer key pairs generation activities and signed witness report, if applicable; and | |
7. Implement controls to confirm that the document signer private key was generated and protected in conformance with the procedures described in the State's certificate policy and/or certification practice statement and the State's key generation script. These requirements must be implemented in full compliance with the following reference: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Section 6.1.1.1. | |
6: Threat Detection | |
6.1 | Implement a System under the control of State or delegated third party trusted roles that continuously monitors, detects, and alerts personnel to any modification to certificate systems, issuing systems, certificate management systems, security support systems, and front-end/internal-support systems, unless the modification has been authorized through a change management process. The State or delegated third party must respond to the alert and initiate a plan of action within at most 24 hours. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity DE.CM-7; and | |
• NIST SP 800-53 Rev. 5, CA-7, CM-3, SI-5. | |
6.2 | Identify any certificate systems under the control of State or delegated third party trusted roles that are capable of monitoring and logging system activity, and enable those systems to log and continuously monitor the events specified in paragraph 7 of this Appendix. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, AU-12. | |
6.3 | Monitor the integrity of the logging processes for application and system logs using either continuous automated monitoring and alerting, or human review, to confirm that logging and log-integrity functions meet the requirements set forth in paragraph 7 of this Appendix. Alternatively, if a human review is utilized and the system is online, the process must be performed at least once every 31 calendar days. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; and | |
• NIST SP 800-53 Rev. 5, AU-1, AU-6, AU-5, AU-9, AU-12. | |
7: Logging | |
7.1 | Log records must include the following elements: |
1. Date and time of record; | |
2. Identity of the person or non-person entity making the journal record; and | |
3. Description of the record. | |
These requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Section 5.4.1; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.PT-1; and | |
• NIST SP 800-53 Rev. 5, AU-2, AU-3, AU-8. | |
7.2 | Log at least certificate system and key lifecycle events for IACA root certificates, document signer certificates, and other intermediate certificates, including: |
1. Key generation, backup, storage, recovery, archival, and destruction; | |
2. Certificate requests, renewal, and re-key requests, and revocation; | |
3. Approval and rejection of certificate requests; | |
4. Cryptographic device lifecycle management events; | |
5. Generation of Certificate Revocation Lists and OCSP entries; | |
6. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles; | |
7. Issuance of certificates; and | |
8. All verification activities required in paragraph 2 of this Appendix and the State's Certification System Policy. | |
These requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Section 5.4.1; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.PT-1; and | |
• NIST SP 800-53 Rev. 5, AU-1, AU-2, AU-3, AU-4, AU-7, AU-10, SC-17. | |
7.3 | Log certificate system Security events, including: |
1. Successful and unsuccessful PKI system access attempts; | |
2. PKI and security system actions performed; | |
3. Security profile changes; | |
4. Installation, update and removal of software on a certificate system; | |
5. System crashes, hardware failures, and other anomalies; | |
6. Firewall and router activities; and | |
7. Entries to and exits from the IACA facility if managed on-premises. | |
These requirements must be implemented in full compliance with the following references: | |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Section 5.4.1; and | |
• NIST SP 800-53 Rev. 5, AU-2, AU-3, AU-4, AU-7, AU-10, CM-3, PE-6, SI-11, SI-12. | |
7.4 | Maintain certificate system logs for a period not less than 36 months, in full compliance with the following references: |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Section 5.4.3; and | |
• NIST SP 800-53 Rev. 5, AU-4, AU-10, AU-11. | |
7.5 | Maintain IACA root certificate and key lifecycle management event logs for a period of not less than 24 months after the destruction of the IACA root certificate private key, in full compliance with the following references: |
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Section 5.4.3; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.PT-1; and | |
• NIST SP 800-53 Rev. 5, AU-2, AU-4, AU-10, AU-11. | |
8: Incident Response & Recovery Plan | |
8.1 | Implement automated mechanisms under the control of State or delegated third party trusted roles to process logged system activity and alert personnel, using notices provided to multiple destinations, of possible critical security events. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity RS.CO-5, RS.AN-5; and | |
• NIST SP 800-53 Rev. 5, AU-1, AU-2, AU-6, IR-5, SI-4, SI-5. | |
8.2 | Require trusted role personnel to follow up on alerts of possible critical security events, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; and | |
• NIST SP 800-53 Rev. 5, AC-5, AC-6, IR-1, IR-4, IR-7, SI-4, SI-5. | |
8.3 | If continuous automated monitoring and alerting is utilized, respond to the alert and initiate a plan of action within 24 hours, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; and | |
• NIST SP 800-53 Rev. 5, IR-1, PM-14, SI-4. | |
8.4 | Implement intrusion detection and prevention controls under the management of State or delegated third party individuals in trusted roles to protect certificate systems against common network and system threats, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• CISA Federal Government Cybersecurity Incident & Vulnerability Response Playbooks; | |
• DHS National Cyber Incident Response Plan; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity DE.AE-2, DE.AE-3; DE.DP-1; and | |
• NIST SP 800-53 Rev. 5, IR-1, IR-4, IR-7, IR-8, SI-4, SI-5. | |
8.5 | Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• CISA Federal Government Cybersecurity Incident & Vulnerability Response Playbooks; | |
• DHS National Cyber Incident Response Plan; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.IP-9; and | |
• NIST SP 800-53 Rev. 5, CA-5, CP-2, CP-4, CP-6, CP-7, CP-8, CP-9, CP-10, SI-1, SI-2, SI-10. | |
8.6 | Notify TSA of any reportable cybersecurity incident, as defined in the TSA Cybersecurity Lexicon available at www.tsa.gov , that may compromise the integrity of the certificate systems within no more than 72 hours of the discovery of the incident. Reports must be made as directed at www.tsa.gov/real-id/mDL . These requirements must be implemented in full compliance with the following references: |
• DHS National Cyber Incident Response Plan; and | |
• NIST SP 800-53 Rev. 5, IR-6. | |
Information provided in response to this paragraph may contain SSI, and if so, must be handled and protected in accordance with 49 CFR part 1520. | |
8.7 | Undergo a vulnerability scan on public and private IP addresses identified by the State or delegated third party as the State's or delegated third party's certificate systems at least every three months, and after performing any significant system or network changes. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; and | |
• NIST SP 800-53 Rev. 5, CM-1, CM-4, IR-3, RA-1, RA-5. | |
8.8 | Undergo a penetration test on the State's and each delegated third party's certificate systems at least every 12 months, and after performing any significant infrastructure or application upgrades or modifications. These requirements must be implemented in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; | |
• NIST Framework for Improving Critical Infrastructure Cybersecurity PR.IP-7; and | |
• NIST SP 800-53 Rev. 5, CA-2, CA-8, CM-4, RA-3. | |
8.9 | Record evidence that each vulnerability scan and penetration test was performed by a person or entity with the requisite skills, tools, proficiency, code of ethics, and independence. |
8.10 | Review State and/or delegated third party incident response & recovery plan at least once during every 12 months to address cybersecurity threats and vulnerabilities, in full compliance with the following references: |
• CA/Browser Forum Network and Certificate System Security Requirements; | |
• DHS National Cyber Incident Response Plan; and | |
• NIST SP 800-53 Rev. 5, CP-2, IR-1, IR-2, SC-5. |