ScotiaConnect applies a layered security model for commercial users: encrypted transport, two-factor authentication, device and IP binding, session controls, and dual-control payment approvals. This reference describes how those layers fit together in the day-to-day experience and what security officers can configure at the company profile level.
Short version. ScotiaConnect security rests on TLS transport, hardware or soft-token two-factor authentication, device binding, IP policy, configurable session limits and server-enforced dual control on payment release.
Transport, identity and access on ScotiaConnect
Audit-ready summary
ScotiaConnect holds a TLS-only front door, enforces strong second-factor authentication for commercial accounts, binds sessions to registered devices and routes every payment release through a server-side dual-control check that cannot be bypassed at the browser.
ScotiaConnect presents a TLS 1.2-and-above front door. Older cipher suites are disabled, and modern browsers negotiate TLS 1.3 where available. Certificate pinning on the mobile app prevents man-in-the-middle attempts against jailbroken or instrumented devices. Treasury users rarely see any of this directly, but internal security reviewers reach for transport evidence first, and the portal's TLS posture is a common first-check during audit field work.
On the identity side, the commercial profile expects a named user, a company-level role, and a second factor bound to an approved device. SMS is not an accepted second factor for commercial profiles. The two supported second-factor types are hardware tokens (OATH-compliant) and approved mobile soft-tokens, with device binding recorded on enrolment. The access guide walks through the enrolment flow step by step.
Dual control is the quiet centrepiece of the ScotiaConnect security model. It is not a browser-side toggle — it is a server-enforced rule tied to the payment template's threshold. An originator cannot release their own batch above threshold, and an attempted bypass is logged in the audit trail. This matches the separation-of-duties expectation that internal auditors and external examiners increasingly require for commercial portal access.
Short version. ScotiaConnect session limits, device binding and optional IP-allow-listing give security officers three configurable controls to tighten the commercial attack surface beyond defaults.
ScotiaConnect ships with sensible session defaults: fifteen-minute inactivity timeout, eight-hour absolute session length, and re-authentication required for high-risk actions regardless of session age. Security officers can tighten both the inactivity and absolute limits on a per-company-profile basis, but cannot extend either beyond the platform-wide maximum set by the bank. This prevents a single client from sliding back to a permissive posture on its own.
Device binding ties a second-factor enrolment to a specific device fingerprint. If the fingerprint changes — new phone, new hardware token, reinstalled app — the security officer has to approve a re-enrolment before the user can authenticate. This is why replacing a lost phone is a one-business-day event rather than an instant reset: the bank wants a human approval between device changes, and so do most client auditors.
IP-allow-listing is optional but popular with regulated-industry clients. When enabled, ScotiaConnect refuses sign-in from addresses outside the declared range. This is useful for clients whose payment operations happen from a fixed corporate network, less so for distributed treasury teams. The Office of the Superintendent of Financial Institutions has published operational-risk guidance that many commercial clients use as the reference point for their own access-control decisions.
Security controls and coverage
Control matrix
The table below summarizes the main ScotiaConnect security controls, the scope each one covers, the default setting out of the box, and whether the client's security officer can override the default at the company-profile level.
ScotiaConnect security controls and coverage
Control
Scope
Default setting
Override possible
TLS transport
All browser and mobile traffic
TLS 1.2 minimum, 1.3 preferred
No
Two-factor authentication
Sign-in and step-up events
Soft-token required
Yes (hardware token)
Device binding
Mobile app and desktop sign-in
Enabled
No
IP allow-list
Desktop sign-in
Disabled
Yes (enable and define)
Inactivity timeout
Browser and mobile sessions
15 minutes
Yes (tighten only)
Absolute session length
Browser and mobile sessions
8 hours
Yes (tighten only)
Dual control on payment release
Above-threshold payment batches
Enforced server-side
No
Positive pay decisioning
Cheque and ACH exception handling
Enabled where product is subscribed
Yes (decision windows)
Positive pay, password hygiene and incident reporting
Short version. Positive pay closes the fraud gap on cheques and ACH debits, password hygiene closes the gap on phishing, and a defined incident-reporting path closes the gap on an unnoticed compromise.
Positive pay sits just outside the authentication controls but inside the security conversation. On ScotiaConnect, a subscribed client uploads a file of issued cheques (or authorizes a list of ACH debit originators) and the portal rejects any item that does not match. Exceptions land in a daily decision queue that an authorized user releases or returns. Positive pay will not prevent an insider release, but it closes the external-fraud gap that most commercial clients worry about first.
Password hygiene on ScotiaConnect is straightforward. Passwords must meet a minimum complexity, cannot be reused within the last ten generations, and are never stored in plaintext. The common user-side failure mode is a browser password manager that remembers the first factor only, giving a false sense of security. Step-up authentication exists precisely to cover this gap, and should not be disabled even if it feels redundant for day-to-day tasks.
Incident reporting is the final layer. If a user suspects unauthorized activity, credential compromise or device loss, the first action is to contact the client security officer, who can suspend the profile immediately. The second action is to notify the commercial service desk at 1-833-245-7669. Cross-border incidents that touch Canadian reporting thresholds may also require notification to FINTRAC under the applicable regime.
Auditor perspective
Short version. External audit teams have described the dual-control and logging posture on ScotiaConnect as workable for commercial-portal evidence during standard field work.
“When we scoped the access-control walkthrough, the exported activity log gave us separation-of-duties evidence without needing a custom pull. Dual control was enforced server-side, not just in the UI. That saved us a day of testing.”
— Olumide J. AkandeSenior IT Auditor, Northstar Freight Systems
Frequently asked questions
Short version. Five questions cover the topics the security desk most often hears: 2FA coverage, hardware-token choice, lost-phone recovery, session length and logging depth on ScotiaConnect.
What does two-factor authentication cover on ScotiaConnect?
Two-factor authentication is required at sign-in and for step-up events: wire release, user-profile changes, positive-pay decisions and certain reporting downloads. The second factor is a hardware token or an approved mobile soft-token. SMS is not an accepted second factor for commercial profiles because of well-documented SIM-swap risk.
Step-up authentication prompts remain in place even within an active session. The user will occasionally be asked for the second factor mid-session before a sensitive action, which is by design.
Can ScotiaConnect users choose a hardware token?
Yes. Hardware tokens are supported and remain the default for regulated segments (dealer desks, trust administrators) or for clients whose internal policy requires an out-of-band second factor. The security officer requests hardware tokens for named users through the onboarding desk.
Soft-tokens are the default for most mid-market clients because issuance and replacement cycles are faster. A lost soft-token is a one-business-day recovery; a lost hardware token is typically three to five business days depending on courier timing.
What happens if a ScotiaConnect user loses a phone?
The user contacts the client security officer, who suspends the device binding and initiates a replacement enrolment. Until the new binding is approved, the user cannot release payments; read-only access can usually be restored within one business day.
Security officers should not attempt to work around this by sharing a second-factor device. Shared tokens break the audit trail and create a separation-of-duties gap that an examiner will flag on the next review.
How long does a ScotiaConnect session stay open?
Default inactivity timeout is fifteen minutes; default absolute session length is eight hours. The security officer can tighten either value but cannot extend beyond the platform maximum. Sensitive actions prompt for step-up authentication regardless of how fresh the session is.
Tightening the inactivity timeout is a common request from clients whose operators share workstations. Five-minute inactivity is a reasonable setting for shared environments; ten minutes is common for dedicated workstations.
What logging exists for ScotiaConnect activity?
ScotiaConnect logs authentication events, payment submissions, approvals, rejections, user-profile changes and report downloads. Retention windows follow the bank's policy and are longer than typical audit-cycle windows. Security officers can export activity logs for internal review through the portal or request a larger extract through the service desk.
Log exports are often used during annual SOC 1 and SOC 2 field work. Auditors appreciate that the export includes the server-side dual-control outcome on each payment release, which is the evidence they usually need for the separation-of-duties control test.