Collapse to view only § 37.9 - Applications for temporary waiver for mDLs.
- § 37.1 - Applicability.
- § 37.3 - Definitions.
- § 37.4 - Incorporation by reference.
- § 37.5 - Validity periods and deadlines for REAL ID driver's licenses and identification cards.
- § 37.7 - Temporary waiver for mDLs; State eligibility.
- § 37.8 - Requirements for Federal agencies accepting mDLs issued by States with temporary waiver.
- § 37.9 - Applications for temporary waiver for mDLs.
- § 37.10 - Application criteria for issuance of temporary waiver for mDLs; audit report; waiver application guidance.
- APPENDIX Appendix A - Appendix A to Subpart A of Part 37—Mobile Driver's License Issuance Infrastructure Requirements
§ 37.1 - Applicability.
(a) Subparts A through E of this part apply to States and U.S. territories that choose to issue driver's licenses and identification cards that can be accepted by Federal agencies for official purposes.
(b) Subpart F establishes certain standards for State-issued driver's licenses and identification cards issued by States that participate in REAL ID, but that are not intended to be accepted by Federal agencies for official purpose under section 202(d)(11) of the REAL ID Act.
§ 37.3 - Definitions.
For purposes of this part:
Administration means management actions performed on Certificate Systems by a person in a Trusted Role.
Birth certificate means the record related to a birth that is permanently stored either electronically or physically at the State Office of Vital Statistics or equivalent agency in a registrant's State of birth.
Card means either a driver's license or identification card issued by the State Department of Motor Vehicles (DMV) or equivalent State office.
Certificate authority means an issuer of digital certificates that are used to certify the identity of parties in a digital transaction.
Certificate management system means a system used by a State or delegated third party to process, approve issuance of, or store digital certificates or digital certificate status information, including the database, database server, and storage.
Certificate policy means the set of rules and documents that forms a State's governance framework in which digital certificates, certificate systems, and cryptographic keys are created, issued, managed, and used.
Certificate system means the system used by a State or delegated third party to provide services related to public key infrastructure for digital identities.
Certification means an assertion by the State to the Department of Homeland Security that the State has met the requirements of this part.
Certified copy of a birth certificate means a copy of the whole or part of a birth certificate registered with the State that the State considers to be the same as the original birth certificate on file with the State Office of Vital Statistics or equivalent agency in a registrant's State of birth.
Covered employees means Department of Motor Vehicles employees or contractors who are involved in the manufacture or production of REAL ID driver's licenses and identification cards, or who have the ability to affect the identity information that appears on the driver's license or identification card.
Critical security event means detection of an event, a set of circumstances, or anomalous activity that could lead to a circumvention of a zone's security controls or a compromise of a certificate system's integrity, including excessive login attempts, attempts to access prohibited resources, Denial of service or Distributed denial of service attacks, attacker reconnaissance, excessive traffic at unusual hours, signs of unauthorized access, system intrusion, or an actual compromise of component integrity.
Data verification means checking the validity of data contained in source documents presented under this regulation.
Delegated third party means a natural person or legal entity that is not the state and that operates any part of a certificate system under the State's legal authority.
Delegated third party system means any part of a certificate system used by a delegated third party while performing the functions delegated to it by the State.
Denial of service means the prevention of authorized access to resources or the delaying of time-critical operations.
Determination means a decision by the Department of Homeland Security that a State has or has not met the requirements of this part and that Federal agencies may or may not accept the driver's licenses and identification cards issued by the State for official purposes.
DHS means the U.S. Department of Homeland Security.
Digital certificates identify the parties involved in an electronic transaction, and contain information necessary to validate Digital signatures.
Digital photograph means a digital image of the face of the holder of the driver's license or identification card.
Digital signatures are mathematical algorithms used to validate the authenticity and integrity of a message.
Distributed denial of service means a denial of service attack where numerous hosts perform the attack.
DMV means the Department of Motor Vehicles or any State Government entity that issues driver's licenses and identification cards, or an office with equivalent function for issuing driver's licenses and identification cards.
Document authentication means determining that the source document presented under these regulations is genuine and has not been altered.
Domestic violence and dating violence have the meanings given the terms in section 3, Universal definitions and grant provisions, of the Violence Against Women and Department of Justice Reauthorization Act of 2005 (Pub. L. 109-162, 119 Stat. 2960, 2964, Jan. 5, 2006); codified at section 40002, Definitions and grant provisions, 42 U.S.C. 13925, or State laws addressing domestic and dating violence.
Driver's license means a motor vehicle operator's license, as defined in 49 U.S.C. 30301.
Duplicate means a driver's license or identification card issued subsequent to the original document that bears the same information and expiration date as the original document and that is reissued at the request of the holder when the original is lost, stolen, or damaged and there has been no material change in information since prior issuance.
Execution environment means a place within a device processer where active application's code is processed.
Federal agency means all executive agencies including Executive departments, a Government corporation, and an independent establishment as defined in 5 U.S.C. 105.
Federally-regulated commercial aircraft means a commercial aircraft regulated by the Transportation Security Administration (TSA).
Front end system means a system with a public IP address, including a web server, mail server, DNS server, jump host, or authentication server.
Full compliance means that the Secretary or his designate(s) has determined that a State has met all the requirements of Subparts A through E.
Full legal name means an individual's first name, middle name(s), and last name or surname, without use of initials or nicknames.
Hardware security module means a physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing.
High security zone means a physical location where a State's or Delegated third party's private key or cryptographic hardware is located.
IAFIS means the Integrated Automated Fingerprint Identification System, a national fingerprint and criminal history system maintained by the Federal Bureau of Investigation (FBI) that provides automated fingerprint search capabilities.
Identification card means a document made or issued by or under the authority of a State Department of Motor Vehicles or State office with equivalent function which, when completed with information concerning a particular individual, is of a type intended or commonly accepted for the purpose of identification of individuals.
Identity proofing refers to a series of steps that the State executes to prove the identity of a person.
Identity verification is the confirmation that identity data belongs to its purported holder.
INS means the former-Immigration and Naturalization Service of the U.S. Department of Justice.
Internal support system means a system which operates on a State's internal network and communicates with the certificate system to provide business services related to mDL management.
Issuing authority means the State that issues a mobile driver's license or mobile identification card.
Issuing authority certificate authority means a certificate authority operated by or on behalf of an issuing authority or a State's root certificate authority.
Issuing system means a system used to sign mDLs, digital certificates, mobile security objects, or validity status information.
Lawful status: A person in lawful status is a citizen or national of the United States; or an alien: lawfully admitted for permanent or temporary residence in the United States; with conditional permanent resident status in the United States; who has an approved application for asylum in the United States or has entered into the United States in refugee status; who has a valid nonimmigrant status in the United States; who has a pending application for asylum in the United States; who has a pending or approved application for temporary protected status (TPS) in the United States; who has approved deferred action status; or who has a pending application for lawful permanent residence (LPR) or conditional permanent resident status. This definition does not affect other definitions or requirements that may be contained in the Immigration and Nationality Act or other laws.
Material change means any change to the personally identifiable information of an individual as defined under this part. Notwithstanding the definition of personally identifiable information below, a change of address of principal residence does not constitute a material change.
Material compliance means a determination by DHS that a State has met the benchmarks contained in the Material Compliance Checklist.
mDL means mobile driver's license and mobile identification cards, collectively.
Mobile driver's license means a driver's license that is stored on a mobile electronic device and read electronically.
Mobile identification card means an identification card, issued by a State, that is stored on a mobile electronic device and read electronically.
Multi-Factor authentication means an authentication mechanism consisting of two or more of the following independent categories of credentials (i.e., factors) to verify the user's identity for a login or other transaction: something you know (knowledge factor), something you have (possession factor), and something you are (inherence factor).
NCIC means the National Crime Information Center, a computerized index of criminal justice information maintained by the Federal Bureau of Investigation (FBI) that is available to Federal, State, and local law enforcement and other criminal justice agencies.
Official purpose means accessing Federal facilities, boarding Federally-regulated commercial aircraft, and entering nuclear power plants.
Online certificate status protocol means an online protocol used to determine the status of a digital certificate.
Passport means a passport booklet or card issued by the U.S. Department of State that can be used as a travel document to gain entry into the United States and that denotes identity and citizenship as determined by the U.S. Department of State.
Penetration test means a process that identifies and attempts to exploit vulnerabilities in systems through the active use of known attack techniques, including the combination of different types of exploits, with a goal of breaking through layers of defenses and reporting on unpatched vulnerabilities and system weaknesses.
Personally identifiable information means any information which can be used to distinguish or trace an individual's identity, such as their name; driver's license or identification card number; social security number; biometric record, including a digital photograph or signature; alone, or when combined with other personal or identifying information, which is linked or linkable to a specific individual, such as a date and place of birth or address, whether it is stored in a database, on a driver's license or identification card, or in the machine readable technology on a license or identification card.
Principal residence means the location where a person currently resides (i.e., presently resides even if at a temporary address) in conformance with the residency requirements of the State issuing the driver's license or identification card, if such requirements exist.
Provisioning means the process by which a State transmits and installs an mDL on an individual's mobile device.
Public key infrastructure means a structure where a certificate authority uses digital certificates for issuing, renewing, and revoking digital credentials.
REAL ID Driver's License or Identification Card means a driver's license or identification card that has been issued by a State that has been certified by DHS to be in compliance with the requirements of the REAL ID Act and which meets the standards of subparts A through D of this part, including temporary or limited-term driver's licenses or identification cards issued under § 37.21.
Reissued card means a card that a State DMV issues to replace a card that has been lost, stolen or damaged, or to replace a card that includes outdated information. A card may not be reissued remotely when there is a material change to the personally identifiable information as defined by the Rule.
Renewed card means a driver's license or identification card that a State DMV issues to replace a renewable driver's license or identification card.
Rich execution environment, also known as a “normal execution environment,” means the area inside a device processor that runs an operating system.
Root certificate authority means the State certificate authority whose public encryption key establishes the basis of trust for all other digital certificates issued by a State.
Root certificate authority system means a system used to create a State's root certificate or to generate, store, or sign with the private key associated with a State root certificate.
SAVE means the DHS Systematic Alien Verification for Entitlements system, or such successor or alternate verification system at the Secretary's discretion.
Secretary means the Secretary of Homeland Security.
Secure element means a tamper-resistant secure hardware component which is used in a device to provide the security, confidentiality, and multiple application environment required to support various business models.
Secure hardware means hardware provided on a mobile device for key management and trusted computation such as a secure element (SE) or trusted execution environment.
Secure key storage device means a device certified as meeting the specified FIPS PUB 140-3 Level 2 overall, Level 3 physical, or Common Criteria (EAL 4+).
Secure zone means an area (physical or logical) protected by physical and logical controls that appropriately protect the confidentiality, integrity, and availability of certificate systems.
Security support system means a system used to provide security support functions, which may include authentication, network boundary control, audit logging, audit log reduction and analysis, vulnerability scanning, and intrusion detection (host-based intrusion detection, network-based intrusion detection).
Sexual assault and stalking have the meanings given the terms in section 3, universal definitions and grant provisions, of the Violence Against Women and Department of Justice Reauthorization Act of 2005 (Pub. L. 109-162, 119 Stat. 2960, 2964, Jan. 5, 2006); codified at section 40002, Definitions and grant provisions, 42 U.S.C. 13925, or State laws addressing sexual assault and stalking.
Sole control means a condition in which logical and physical controls are in place to ensure the administration of a certificate system can only be performed by a State or delegated third party.
Source document(s) means original or certified copies (where applicable) of documents presented by an applicant as required under these regulations to the Department of Motor Vehicles to apply for a driver's license or identification card.
State means a State of the United States, the District of Columbia, Puerto Rico, the Virgin Islands, Guam, American Samoa, and the Commonwealth of the Northern Mariana Islands.
State address confidentiality program means any State-authorized or State-administered program that—
(1) Allows victims of domestic violence, dating violence, sexual assault, stalking, or a severe form of trafficking to keep, obtain, and use alternative addresses; or
(2) Provides confidential record-keeping regarding the addresses of such victims or other categories of persons.
State root certificate means a public digital certificate of a root certificate authority operated by or on behalf of a State.
System means one or more pieces of equipment or software that stores, transforms, or communicates data.
Temporary lawful status: A person in temporary lawful status is a person who: Has a valid nonimmigrant status in the United States (other than a person admitted as a nonimmigrant under the Compacts of Free Association between the United States and the Republic of the Marshall Islands, the Federated States of Micronesia, or the Republic of Palau); has a pending application for asylum in the United States; has a pending or approved application for temporary protected status (TPS) in the United States; has approved deferred action status; or has a pending application for LPR or conditional permanent resident status.
Trusted execution environment means an execution environment that runs alongside but isolated from a rich execution environment and has the security capabilities necessary to protect designated applications.
Trusted role means an employee or contractor of a State or delegated third party who has authorized access to or control over a secure zone or high security zone.
Verify means procedures to ensure that:
(1) The source document is genuine and has not been altered (i.e., “document authentication”); and
(2) The identity data contained on the document is valid (“data verification”).
Virtual local area network means a broadcast domain that is partitioned and isolated within a network.
Vulnerability means a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.
Vulnerability scanning means a technique used to identify host attributes and associated vulnerabilities.
Zone means a subset of certificate systems created by the logical or physical partitioning of systems from other certificate systems.
§ 37.4 - Incorporation by reference.
Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the Transportation Security Administration (TSA) and at the National Archives and Records Administration (NARA). Please contact TSA at Transportation Security Administration, Attn.: OS/ESVP/REAL ID Program, TSA Mail Stop 6051, 6595 Springfield Center Dr., Springfield, VA 20598-6051, (866) 289-9673, or visit www.tsa.gov. You may also contact the REAL ID Program Office at [email protected] or visit www.tsa.gov/REAL-ID/mDL. For information on the availability of this material at NARA, visit www.archives.gov/federal-register/cfr/ibr-locations.html or email [email protected]. The material may also be obtained from the following sources:
(a) American Association of Motor Vehicle Administrators (AAMVA) 4301 Wilson Boulevard, Suite 400, Arlington, VA 22203; phone: (703) 522-4200; website: www.aamva.org.
(1) 2005 AAMVA Driver's License/Identification Card Design Specifications, Annex A, section A.7.7.2., March 2005 (AAMVA Specifications); IBR approved for § 37.17.
(2) Mobile Driver's License (mDL) Implementation Guidelines, Version 1.2January 2023; IBR approved for § 37.10(a). (Available at https://aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation-Guidelines-Version-1-2_final.pdf.)
(b) Certification Authority Browser Forum (CA/Browser Forum), 815 Eddy St., San Francisco, CA 94109; phone: (415) 436-9333; email: [email protected]; website: www.cabforum.org.
(1) Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Version 1.8.6, December 14, 2022; IBR approved for appendix A to this subpart. (Available at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.6.pdf.)
(2) Network and Certificate System Security Requirements, Version 1.7, April 5, 2021; IBR approved for appendix A to this subpart. (Available at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Network-Security-Guidelines-v1.7.pdf.)
(c) Cybersecurity and Infrastructure Security Agency, Mail Stop 0380, Department of Homeland Security, 245 Murray Lane, Washington, DC 20528-0380; phone: (888) 282-0870; email: [email protected]; website: www.cisa.gov.
(1) Federal Government Cybersecurity Incident & Vulnerability Response Playbooks, November 2021; IBR approved for appendix A to this subpart. (Available at www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf.)
(2) [Reserved]
(d) Department of Homeland Security, 2707 Martin Luther King Jr. Ave. SE, Washington, DC 20528; phone: (202) 282-8000; website: www.dhs.gov.
(1) National Cyber Incident Response Plan, December 2016; IBR approved for appendix A to this subpart. (Available at www.cisa.gov/uscert/sites/default/files/ncirp/National_Cyber_Incident_Response_Plan.pdf.)
(2) [Reserved]
(e) International Civil Aviation Organization (ICAO), ICAO, Document Sales Unit, 999 University Street, Montreal, Quebec, Canada H3C 5H7; phone: (514) 954-8219; email: [email protected]; website: www.icao.int.
(1) ICAO 9303, “Machine Readable Travel Documents,” Volume 1, part 1, Sixth Edition, 2006; IBR approved for § 37.17.
(2) [Reserved]
(f) International Organization for Standardization, Chemin de Blandonnet 8, CP 401, 1214 Vernier, Geneva, Switzerland; phone: +41 22 749 01 11; email: [email protected]; website: www.iso.org/contact-iso.html. (Also available by contacting ANSI at ANSI, 25 West 43rd Street, 4th Floor, New York, New York 10036 website: www.ansi.org.)
(1) ISO/IEC 19794-5:2005(E) Information technology—Biometric Data Interchange Formats—Part 5: Face Image Data, dated June 2005; IBR approved for § 37.17.
(2) ISO/IEC 15438:2006(E) Information Technology—Automatic identification and data capture techniques—PDF417 symbology specification, dated June 2006; IBR approved for § 37.19.
(3) ISO/IEC 18013-5:2021(E), Personal identification—ISO-compliant driving license—Part 5: Mobile driving license (mDL) application, First Edition, September 2021; IBR approved for §§ 37.8(b); 37.10(a); and appendix A to this subpart.
(g) National Institute of Standards and Technology, 100 Bureau Drive, Gaithersburg, MD 20899; phone: (301) 975-2000; website: www.nist.gov.
(1) FIPS PUB 140-3, Federal Information Processing Standard Publication: Security Requirements for Cryptographic Modules, March 22, 2019; IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf.)
(2) FIPS PUB 180-4, Federal Information Processing Standard Publication: Secure Hash Standard (SHS), August 2015; IBR approved for § 37.10(a). (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf.)
(3) FIPS PUB 186-5, Federal Information Processing Standard Publication: Digital Signature Standard (DSS), February 3, 2023; IBR approved for § 37.10(a). (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf.)
(4) FIPS PUB 197-upd1, Federal Information Processing Standard Publication: Advanced Encryption Standard (AES), May 9, 2023; IBR approved for § 37.10(a). (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.)
(5) FIPS PUB 198-1, Federal Information Processing Standard Publication: The Keyed-Hash Message Authentication Code (HMAC), July 2008; IBR approved for § 37.10(a). (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf.)
(6) FIPS PUB 202, Federal Information Processing Standard Publication: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015; IBR approved for § 37.10(a). (Available at https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf.)
(7) NIST SP 800-53 Rev.5, NIST Special Publication: Security and Privacy Controls for Information Systems and Organizations, Revision 5, September 2020 (including updates as of December. 10, 2020); IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf.)
(8) NIST SP 800-57 Part 1 Rev.5, NIST Special Publication: Recommendation for Key Management: Part 1—General, Revision 5, May 2020; IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf.)
(9) NIST SP 800-57 Part 2 Rev.1, NIST Special Publication: Recommendation for Key Management: Part 2—Best Practices for Key Management Organization, Revision 1, May 2019; IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf.)
(10) NIST SP 800-57 Part 3 Rev.1, NIST Recommendation for Key Management: Part 3: Application-Specific Key Management Guidance, Revision 1, January 2015; IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf.)
(11) NIST SP 800-63-3, NIST Special Publication: Digital Identity Guidelines, June 2017; IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf.)
(12) NIST SP 800-63B, NIST Special Publication: Digital Identity Guidelines Authentication and Lifecycle Management, June 2017 (including updates as of December. 1, 2017); IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.)
(13) NIST Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1, April 16, 2018); IBR approved for appendix A to this subpart. (Available at https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf.)
§ 37.5 - Validity periods and deadlines for REAL ID driver's licenses and identification cards.
(a) Driver's licenses and identification cards issued under this part, that are not temporary or limited-term driver's licenses and identification cards, are valid for a period not to exceed eight years. A card may be valid for a shorter period based on other State or Federal requirements.
(b) On or after May 7, 2025, Federal agencies shall not accept a driver's license or identification card for official purposes from any individual unless such license or card is a REAL ID-compliant driver's license or identification card issued by a State that has been determined by DHS to be in full compliance as defined under this subpart.
(c) Through the end of May 6, 2025, Federal agencies may accept for official purposes a driver's license or identification card issued under § 37.71. On or after May 7, 2025, Federal agencies shall not accept for official purposes a driver's license or identification card issued under § 37.71.
§ 37.7 - Temporary waiver for mDLs; State eligibility.
(a) Generally. TSA may issue a temporary certificate of waiver to a State that meets the requirements of §§ 37.10(a) and (b).
(b) State eligibility. A State may be eligible for a waiver only if, after considering all information provided by a State under §§ 37.10(a) and (b), TSA determines that—
(1) The State is in full compliance with all applicable REAL ID requirements as defined in subpart E of this part; and
(2) Information provided by the State under §§ 37.10(a) and (b) sufficiently demonstrates that the State's mDL provides the security, privacy, and interoperability necessary for acceptance by Federal agencies.
§ 37.8 - Requirements for Federal agencies accepting mDLs issued by States with temporary waiver.
Notwithstanding § 37.5(b), Federal agencies may accept an mDL for REAL ID official purposes issued by a State that has a valid certificate of waiver issued by TSA under § 37.7(a). A Federal agency that elects to accept mDLs under this section must—
(a) Confirm the State holds a valid certificate of waiver consistent with § 37.7(a) by verifying that the State appears in a list of mDLs approved for Federal use, available as provided in § 37.9(b)(1);
(b) Use an mDL reader to retrieve and validate mDL data as required by standard ISO/IEC 18013-5:2021(E) (incorporated by reference; see § 37.4);
(c) In accordance with the deadlines set forth in § 37.5, verify that the data element “DHS_compliance” is marked “F”, as required by §§ 37.10(a)(4)(ii) and (a)(1)(vii); and
(d) Upon discovery that acceptance of a State's mDL is likely to cause imminent or serious threats to the security, privacy, or data integrity, the agency's senior official responsible for REAL ID compliance, or equivalent function, must report such discovery to TSA as directed at www.tsa.gov/real-id/mDL within 72 hours of such discovery. 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.
§ 37.9 - Applications for temporary waiver for mDLs.
(a) Application process. Each State requesting a temporary waiver must file with TSA a complete application as set forth in §§ 37.10(a) and (b). Application filing instructions may be obtained from TSA at www.tsa.gov/real-id/mDL.
(b) Decisions. TSA will provide written notice via email to States within 60 calendar days, to the extent practicable, but in no event longer than 90 calendar days, indicating that TSA has made one of the following decisions:
(1) Approved. Upon approval of an application for a temporary waiver, TSA will issue a certificate of waiver to the State, and publish the State's name in a list of mDLs approved for Federal use at www.tsa.gov/real-id/mDL.
(2) Insufficient. Upon determination that an application for a temporary waiver is incomplete or otherwise deficient, TSA will provide the State an explanation of deficiencies, and an opportunity to address any deficiencies and submit an amended application. States will have 60 calendar days to respond to the notice, and TSA will respond via email within 30 calendar days.
(3) Denied. Upon determination that an application for a waiver fails to meet criteria specified in §§ 37.10(a) and (b), TSA will provide the State specific grounds on which the denial is based, and provide the State an opportunity to seek reconsideration as provided in paragraph (c) of this section.
(c) Reconsideration—(1) How to File Request. States will have 90 calendar days to file a request for reconsideration of a denied application. The State must explain what corrective action it intends to implement to correct any defects cited in the denial or, alternatively, explain why the denial is incorrect. Instructions on how to file a request for reconsideration for denied applications may be obtained from TSA at www.tsa.gov/real-id/mDL. TSA will notify States of its final determination within 60 calendar days of receipt of a State's request for reconsideration.
(2) Final agency action. An adverse decision upon reconsideration is a final agency action. A State whose request for reconsideration has been denied may submit a new application at any time following the process set forth in paragraph (a) of this section.
(d) Terms and conditions. A certificate of waiver will specify—
(1) The effective date of the waiver;
(2) The expiration date of the waiver; and
(3) Any additional terms or conditions as necessary.
(e) Limitations; suspension; termination—(1) Validity period. A certificate of waiver is valid for a period of 3 years from the date of issuance.
(2) Reporting requirements. If a State, after it has been granted a certificate of waiver, makes any significant additions, deletions, or modifications to its mDL issuance processes, other than routine systems maintenance and software updates, that differ materially from the information the State provided in response to §§ 37.10(a) and (b) under which the waiver was granted, the State must provide written notice of such changes to TSA at www.tsa.gov/real-id/mDL 60 calendar days before implementing such additions, deletions, or modifications. If a State is uncertain whether its particular changes require reporting, the State may contact TSA as directed at www.tsa.gov/real-id/mDL.
(3) Compliance. A State that is issued a certificate of waiver under this section must comply with all applicable REAL ID requirements in § 37.51(a), and with all terms and conditions specified in paragraph (d)(3) of this section.
(4) Suspension. (i) TSA may suspend the validity of a certificate of waiver for any of the following reasons:
(A) Failure to comply. TSA determines that a State has failed to comply with paragraph (d)(3) or (e)(2) of this section, or has issued mDLs in a manner not consistent with the information provided under §§ 37.10(a) or (b); or
(B) Threats to security, privacy, and data integrity. TSA reserves the right to suspend a certificate of waiver at any time upon discovery that Federal acceptance of a State's mDL is likely to cause imminent or serious threats to the security, privacy, or data integrity of any Federal agency. In such instances, TSA will provide written notice via email to each affected State as soon as practicable after discovery of the triggering event, including reasons for suspension, an explanation of any corrective actions a State must take to resume validity of its certificate of waiver.
(ii) Before suspending a certificate of waiver under paragraph (e)(4)(i)(A) of this section, TSA will provide to such State written notice via email of intent to suspend, including an explanation of deficiencies and instructions on how the State may cure such deficiencies. States will have 30 calendar days to respond to the notice, and TSA will respond via email within 30 calendar days. TSA's response would include one of the following: withdrawal of the notice, a request for additional information, or a final suspension.
(iii) If TSA issues a final suspension, TSA will temporarily remove the State from the list of mDLs approved for Federal acceptance for official purposes. TSA will continue to work with a State to whom TSA has issued a final suspension to resume validity of its existing certificate of waiver. A State that has been issued a final suspension may seek a new certificate of waiver by submitting a new application following the process set forth in paragraph (a) of this section.
(5) Termination. (i) TSA may terminate a certificate of waiver at an earlier date than specified in paragraph (d)(2) of this section if TSA determines that a State—
(A) Does not comply with applicable REAL ID requirements in § 37.51(a);
(B) Is committing an egregious violation of requirements specified under paragraph (d)(3) or (e)(2) of this section that the State is unwilling to cure; or
(C) Provided false information in support of its waiver application.
(ii) Before terminating a certificate of waiver, TSA will provide the State written notice via email of intent to terminate, including findings on which the intended termination is based, together with a notice of opportunity to present additional information. States must respond to the notice within 7 calendar days, and TSA will reply via email within 30 calendar days. TSA's response would include one of the following: withdrawal of the notice, a request for additional information, or a final termination.
(iii) If TSA issues a final termination, TSA will remove the State from the list of mDLs approved for Federal acceptance for official purposes. A State whose certificate of waiver has been terminated may seek a new waiver by submitting a new application following the process set forth in paragraph (a) of this section.
(6) Reapplication. A State seeking extension of a certificate of waiver after expiration of its validity period must file a new application under paragraph (a) of this section.
(f) Effect of status of certificate of waiver. (1) Issuance of a certificate of waiver is not a determination of compliance with any other section in this part.
(2) An application for certificate of waiver that TSA has deemed insufficient or denied, or a certificate of waiver that TSA has deemed suspended, terminated, or expired, is not a determination of non-compliance with any other section in this part.
(g) SSI. Information provided in response to paragraphs (a), (b)(2), (c), (e)(2), (e)(4)(ii), and (e)(5)(ii) of this section may contain SSI, and if so, must be handled and protected in accordance with 49 CFR part 1520.
§ 37.10 - Application criteria for issuance of temporary waiver for mDLs; audit report; waiver application guidance.
(a) Application criteria. A State requesting a certificate of waiver must establish in its application that the mDLs for which the State seeks a waiver are issued with controls sufficient to resist compromise and fraud attempts, provide privacy protections sufficient to safeguard an mDL holder's identity data, and provide interoperability for secure acceptance by Federal agencies under the terms of a certificate of waiver. To demonstrate compliance with such requirements, a State must provide information, documents, and/or data sufficient to explain the means, which includes processes, methodologies, or policies, that the State has implemented to comply with requirements in this paragraph (a).
(1) Provisioning. For both remote and in-person provisioning, a State must explain the means it uses to address or perform the following—
(i) Data encryption. Securely encrypt mDL data and an mDL holder's Personally Identifiable Information when such data is transferred during provisioning, and when stored on the State's system(s) and on mDL holders' mobile devices.
(ii) Escalated review. Review repeated failed attempts at provisioning, resolve such failures, and establish criteria to determine when the State will deny provisioning an mDL to a particular mDL applicant.
(iii) Authentication. Confirm that an mDL applicant has control over the mobile device to which an mDL is being provisioned at the time of provisioning.
(iv) Device identification keys. Confirm that the mDL applicant possesses the mDL device private key bound to the mDL during provisioning.
(v) User identity verification. Prevent an individual from falsely matching with the licensing agency's records, including portrait images, of other individuals.
(vi) Applicant presentation. Prevent physical and digital presentation attacks by detecting the liveness of an individual and any alterations to the individual's appearance during remote and in-person provisioning.
(vii) DHS_compliance data element. Set the value of data element “DHS_compliance”, as required by paragraph (a)(4)(ii) of this section, to correspond to the REAL ID compliance status of the underlying physical driver's license or identification card that a State has issued to an mDL holder as follows—
(A) “F” if the underlying card is REAL ID-compliant, or as otherwise required by AAMVA Mobile Driver's License (mDL) Implementation Guidelines, Section 3.2 (incorporated by reference; see § 37.4); or
(B) “N” if the underlying card is not REAL ID-compliant.
(viii) Data record. Issue mDLs using data, including portrait image, of an individual that matches corresponding data in the database of the issuing State's driver's licensing agency for that individual.
(ix) Records retention. Manage mDL records and related records, consistent with requirements set forth in AAMVA Mobile Driver's License (mDL) Implementation Guidelines (incorporated by reference; see § 37.4).
(2) Issuance. A State must explain the means it uses to manage the creation, issuance, use, revocation, and destruction of the State's certificate systems and keys in full compliance with the requirements set forth in appendix A to this subpart.
(3) Privacy. A State must explain the means it uses to protect Personally Identifiable Information during processing, storage, and destruction of mDL records and provisioning records.
(4) Interoperability. A State must explain the means it uses to issue mDLs that are interoperable with ISO/IEC 18013-5:2021(E) and the “AAMVA mDL data element set” defined in the AAMVA Mobile Driver's License (mDL) Implementation Guidelines (incorporated by reference; see § 37.4) as follows:
(i) A State must issue mDLs using the data model defined in ISO/IEC 18103-5:2021(E) section 7 (incorporated by reference; see § 37.4), using the document type “org.iso.18013.5.1.mDL”, and using the name space “org.iso.18013.5.1”. States must include the following mDL data elements defined as mandatory in ISO/IEC 18103-5:2021(E) Table 5: “family_name”, “given_name”, “birth_date”, “issue_date”, “expiry_date”, “issuing_authority”, “document_number”, “portrait”, and must include the following mDL data elements defined as optional in Table 5: “sex”, “resident_address”, “portrait_capture_date”, “signature_usual_mark”.
(ii) States must use the AAMVA mDL data element set defined in AAMVA Mobile Driver's License (mDL) Implementation Guidelines, Section 3.2 (incorporated by reference; see § 37.4), using the namespace “org.iso.18013.5.1.aamva” and must include the following data elements in accordance with the AAMVA mDL Implementation Guidelines: “DHS_compliance”, and “DHS_temporary_lawful_status”.
(iii) States must use only encryption algorithms, secure hashing algorithms, and digital signing algorithms as defined by ISO/IEC 18103-5:2021(E), section 9 and Annex B (incorporated by reference; see § 37.4), and which are included in the following NIST Federal Information Processing Standards (FIPS): NIST FIPS PUB 180-4, NIST FIPS PUB 186-5, NIST FIPS PUB 197-upd1, NIST FIPS PUB 198-1, and NIST FIPS PUB 202 (incorporated by reference; see § 37.4).
(b) Audit report. States must include with their applications a report of an audit that verifies the information provided under paragraph (a) of this section.
(1) The audit must be conducted by a recognized independent entity, which may be an entity that is employed or contracted by a State and independent of the State's driver's licensing agency,—
(i) Holding an active Certified Public Accountant license in the issuing State;
(ii) Experienced with information systems security audits;
(iii) Accredited by the issuing State; and
(iv) Holding a current and active American Institute of Certified Public Accountants (AICPA) Certified Information Technology Professional (CITP) credential or ISACA (F/K/A Information Systems Audit and Control Association) Certified Information System Auditor (CISA) certification.
(2) States must include information about the entity conducting the audit that identifies—
(i) Any potential conflicts of interest; and
(ii) Mitigation measures or other divestiture actions taken to avoid conflicts of interest.
(c) Waiver application guidance—(1) Generally. TSA will publish “Mobile Driver's License Waiver Application Guidance” to facilitate States' understanding of the requirements set forth in paragraph (a) of this section. The non-binding Guidance will include recommendations and examples of possible implementations for illustrative purposes only. TSA will publish the Guidance on the REAL ID website at www.tsa.gov/real-id/mDL.
(2) Updates. TSA may periodically update its Waiver Application Guidance as necessary to provide additional information or recommendations to mitigate evolving threats to security, privacy, or data integrity. TSA will publish a notification in the
Appendix A - Appendix A to Subpart A of Part 37—Mobile Driver's License Issuance Infrastructure Requirements
A State that issues mDLs for acceptance by Federal agencies for official purposes as specified in the REAL ID Act must implement the requirements set forth in this appendix A in full compliance with the cited references. All references identified in this appendix A are incorporated by reference, see § 37.4. If a State utilizes the services of a delegated third party, the State must ensure the delegated third party complies with all applicable requirements of this appendix A for the services provided.
Paragraph | Requirement | 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.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.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.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.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.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.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.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 | • DHS National Cyber Incident Response Plan; and | • NIST SP 800-53 Rev. 5, IR-6. | Information provided in response to this paragraph | 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. |
---|