Identification and Authentication. Customer shall assure that any access to any database related to the Cloud Services, whether by Customer or SAP, is automatically disconnected after a period of no-activity and that it has in place a method of handling malfunctions connected with identification authentication, all in accordance with the requirements under Section 9 of the Regulations.
Identification and Authentication. For access to In-Scope Information and for host devices that support it, assign unique credentials (eg. UserIDs, passwords) to authorized individual users, assign individual ownership to system service accounts, and ensure that system service accounts are not shared by administrators.
Identification and Authentication. The purpose of authentication is to provide reliable identification for access to data or information systems. Entity must maintain the identity of active users, linking actions to specific users, and all other identification and authentication requirements. Non-repudiation must be maintained for each user accessing DPS data.
Identification and Authentication. All access to any Customer Information or any West Processing Resources shall be Identified and Authenticated as defined in this Section. “Identification” refers to processes which establish the identity of the person or entity requesting access to Customer Information and/or West Processing Resources. “Authentication” refers to processes which validate the purported identity of the requestor. For access to Customer Information or West Processing Resources, West shall require Authentication by the use of an individual, unique user ID and an individual password and/or other appropriate Authentication technique (e.g. soft token, pin, etc.). West shall obtain written approval from Customer prior to using digital certificates as part of West’s Identification or Authorization processes. West shall maintain procedures to ensure the protection, integrity, and soundness of all passwords created by West and/or used by West in connection with the Agreement.
Identification and Authentication. All access to any Mercury Information or any Global Processing Resources shall be Identified and Authenticated as defined in this Section. “Identification” refers to processes which establish the identity of the person or entity requesting access to Mercury Information and/or Global Processing Resources. “Authentication” refers to processes which validate the purported identity of the requestor. For access to Mercury Information or Global Processing Resources, each party shall require *****. Each party shall maintain its own procedures to ensure the protection, integrity, and soundness of all passwords created and/or used in connection with the Agreement.
Identification and Authentication. Each user who shares data as part of the eHealth Exchange shall be uniquely identified and their identity verified prior to granting access to a Participant’s system.
Identification and Authentication. The data importer shall take the measures that ensures the identification and authentication of the users. The data importer shall establish a mechanism that permits the identification of any user who tries to access the information system and the verification of his authorization. The data importer’s documentation shall establish the frequency, which under no circumstances shall be less than yearly, with which the passwords shall be changed. While in force, passwords shall be stored in an unintelligible way.
Identification and Authentication. User ID Requirements. The PSAP Manager shall require a unique logon ID to the Call Handling software system for every dispatcher (but not the PC Windows): Password Requirements. PSAP shall include the following minimum standards for establishing passwords:
Identification and Authentication. 11.1 In relation to access to Subscriber Data, either in electronic or hard copy, by the Supplier’s team, the Supplier shall:
(a) Ensure such access is limited to a minimal set of authorized users.
(b) Assign unique User IDs to individual users.
(c) Have and use a documented User ID lifecycle management process including procedures for approved account creation, account removal immediately on termination or within 24 hours on role change, and account modification (e.g., changes to privileges, span of access, functions/roles) for all Information Resources and across all environments (e.g., production, test, development, etc.). Such process shall include review of access privileges and account validity to be performed at least quarterly.
(d) Enforce the rule of least privilege (i.e., limiting access to only the commands and Information Resources necessary to perform authorized functions according to one’s job function).
(e) Limit failed login attempts to no more than five (5) successive attempts and lock the user account upon reaching that limit. Access to the user account can be reactivated subsequently through a manual process requiring verification of the user’s identity or, where such capability exists.
(f) Terminate interactive sessions, or activate a secure, locking screensaver requiring authentication, after a period of inactivity not to exceed fifteen (15) minutes.
(g) Require password expiration at regular intervals not to exceed sixty (60) days.
(h) Use an authentication method based on the sensitivity of Subscriber Data.
(i) Whenever authentication credentials are stored, protect them using Strong Encryption.
(j) When passwords are used, ensure they are complex and at least meet the following password construction requirements:
(i) Be a minimum of eight (8) characters in length.
(ii) Contain characters from at least three (3) of these groupings: uppercase letter, lower case letter, numeric, and special characters.
(iii) Not be the same as the User ID with which they are associated.
(iv) Not contain repeating or sequential characters or numbers.
(k) Use a secure method for the conveyance of authentication credentials (e.g., passwords) and authentication mechanisms (e.g., tokens or smart cards).
11.2 Applications housing sensitive copies of Subscriber Data may require an authentication mechanism stronger than passwords. In such case, the authentication mechanism shall be mutually agreed to by the Parties in advance in writing. Examples of stronger a...
Identification and Authentication. 12.1 In relation to access to Xxxxxxx Data, either in electronic or hard copy, by the Supplier’s team, the Supplier shall:
(a) Require Strong Authentication (i.e. Multi-factor authentication) for any remote access use of non-public Information Resources
(b) Ensure that access to systems that process Xxxxxxx Data is enforced through a centralized identity provider that conforms to industry best practise.
(c) Use a secure method for the conveyance of authentication credentials (i.e. passwords) and authentication mechanisms (i.e. tokens or smart cards)
(d) Where appropriate adopt a risk-based authentication mechanism such that authentication methods are tiered and proportionate to the sensitivity of the Xxxxxxx Data to be accessed (i.e. the use of stronger form of authentication for accessing Xxxxxxx Personal Information)
(e) Have and use a documented User ID lifecycle management process including procedures for approved account creation, account removal immediately on termination or within 24 hours on role change, and account modification (i.e. changes to privileges, span of access, functions/roles) for all Information Resources and across all environments (e.g., production, test, development, etc.). Such process shall include review of access privileges and account validity to be performed at least quarterly.
