Strong Authentication Clause Samples

Strong Authentication. In accordance with the regulations applicable as of the coming into effect of paragraphs I, II and III of article L. 133-44 of the French Monetary and Financial Code, the Bank shall apply measures for strong authentication of the Client when the Client: - accesses its account online under the conditions set out in the online banking communication service contract entered into with the Bank; - initiates an electronic payment transaction; - executes a transaction through the intermediary of an online communication method likely to carry a risk of fraud in terms of payment or of any other fraudulent use. The Bank reserves the right to override the obligation to apply measures of strong authentication in the cases specifically referred to by applicable regulations and in particular the technical requirements of regulations concerning authentication and communication.

Strong Authentication. SELLER will maintain capability for its Services to integrate with P&G’s Federation Service. SELLER will use multi-factor authentication for any of the following: 6.1 Privileged access (e.g. system or data base level administrative access) to any servers and/or applications hosting P&G INFORMATION; 6.2 Any remote access by SELLER to P&G INFORMATION.

Strong Authentication. (a) To the extent implemented under Existing Customer Security Controls, multi-factor authentication (“MFA”) shall be used to restrict access to Customer Confidential Information, Customer Data, and Customer Systems. (b) Where MFA is not an Existing Customer Security Control, Provider shall use authentication mechanisms and authentication methodologies described in the CSD, or if not described in the CSD, shall maintain the mechanism and methodologies in place for Customer Systems as of the Effective Date, subject to the Change Control Procedures if Customer subsequently requests a different mechanism or methodology. (c) Provider shall use strong authentication mechanisms and authentication methodologies that meet or exceed prevailing industry standards for similar systems as well as mandatory security requirements under applicable Provider Laws to restrict access to Provider Systems used to collect, store, or otherwise process Customer Confidential Information and Customer Data.

Strong Authentication. Supplier will use two-factor authentication and certificates to authenticate their remote administrators who manage their cloud services, or an alternative strong authentication method provided it has received prior approval from Seagate.

Strong Authentication. As previously mentioned we ensure strong authentication by typing the log recv function: val log recv: s: uint32 c: uint16 ST (unit) (requires (fun h List.for all (fun e (Recv s c) <> e) (sel h log p) c > cnt max (sel h log p))) (ensures (fun h x h’ sel h’ log p = Recv s c :: sel h log p c = cnt max (sel h’ log p))) (modifies (a ref log p)) Among other conditions, this type requires that whenever we log a Recv s c event, the event is not present in the log. Typing every call of log recv, in combination with the assume/assert mechanism, provides the desired injective correspondence: no more than a single occurrence of a receive event can appear in the log and whenever we accept a message, it is produced by the honest principal. We achieve this result by proving the following lemma and invariant: ▇▇▇ ▇▇▇ ▇▇▇▇▇: s:uint32 → c:uint16 → (l:list event{c > cnt max l}) → Lemma(∀ e . List.mem e l =⇒ (Recv s c) <> e) let invariant h = cnt max (sel h log p) = sel h receiver cnt && Heap.contains h receiver cnt && Heap.contains h sender cnt && Heap.contains h log p && receiver cnt <> sender cnt Intuitively, max lemma asserts that whenever we receive a signal s that is signed with a counter c greater than all the counters in the log, then the event Recv s c is not in the log. The invariant ensures that a set of properties are maintained on the heap across executions of sender and receiver. In particular, we maintain the invariant that the highest counter in log p is equal to the current value of receiver cnt, and that the sender cnt and receiver cnt are disjoint memory locations, hence sender and receiver do not interfere.

Strong Authentication. You will enforce Strong Authentication for any remote access to RingCentral Personal Information and any remote use of Nonpublic Information Resources. Additionally, You will enforce Strong Authentication for any administrative and/or management access to Your security infrastructure and Your log data including but not limited to firewalls, Identity and Access Management systems, security monitoring infrastructure, and computing logs such as firewall logs, server logs, DNS logs, etc.

Strong Authentication. In accordance with the Bank’s practices, protests of cheques and securities deposited by the Client may only be made by written request from the Client. Since postal and protest formulation time frames make it very difficult to comply with legal deadlines, the Client shall waive opposition to any lapse by the Bank and shall release it from all liability for late or delayed presentation, or failure to send any notice of non-payment or non-acceptance in the event of negligence by the Bank.