Nine layers of account defence
Adroite Capitorc combines access safeguards, encrypted data handling, restricted connections and incident support. These measures reduce specific threats; they do not eliminate cyber risk, provider risk or investment loss.
Multi-factor authentication adds a second check after the password. Supported methods can include an authenticator application and a one-time verification code delivered through a confirmed channel. We recommend enabling the strongest available method immediately after account activation, even when a particular account state does not make it mandatory.
Recovery is deliberately separate from ordinary login. If a device is lost, support may ask for identity evidence, recent account context and confirmation through an existing trusted channel. A request to remove the second factor can be delayed while unusual activity is assessed. Support will never ask a client to read out a current authentication code so that an employee can sign in.
Connections between a supported browser and our web systems use current encrypted transport so information is less exposed while moving across networks. Sensitive records stored by systems under our control are protected with access restrictions and encryption appropriate to the record type. Keys and administrative permissions are separated from routine support access.
Encryption is one component, not proof that every endpoint is safe. Malware on a client device, a deceptive website or access granted to an untrusted third party can expose information before or after encryption applies. Keep the operating system and browser current, use a secured network and verify the domain before entering details.
Official website communications use the https://adroite-capitorc.org domain and support questions are handled through [email protected]. Look-alike domains, altered spellings and unsolicited social-media contacts are common impersonation methods. A message that creates pressure, requests secrecy or directs a payment to a new destination should be treated as suspicious until independently confirmed.
Where a verified-message or security-code feature is available, use it to distinguish expected correspondence. Do not follow a link solely because a logo and staff name appear genuine. Open the site from a saved address, compare the full domain and contact support using details you already trust. Report suspected clones through the Fraud Warning page.
Alerts may be sent when a new device signs in, a password or security setting changes, a connection is created or behaviour appears inconsistent with the established account pattern. Delivery can depend on the client’s confirmed email, device notification settings and service availability. Alerts should be reviewed promptly rather than assumed to be promotional messages.
If an alert is unfamiliar, change the password from a trusted device, revoke unknown sessions and contact support. Preserve the message and note the approximate time, but do not forward a verification code or complete account secret. An alert is an opportunity to limit harm; it is not confirmation that funds or data have already been lost.
The account view can identify active sessions and recognized devices with details such as approximate location, browser and last activity. Clients should review the list periodically and after travel, a device replacement or any suspicious message. Sessions that are no longer required can be revoked without waiting for their normal expiry.
Automatic expiry limits how long an inactive session remains usable, while higher-risk actions may require renewed authentication. Shared computers and public terminals should not be marked as trusted. Signing out is necessary, but clearing saved credentials and avoiding browser synchronization on a shared device are also important.
Recovery balances access with protection against takeover. A client may be asked to confirm contact details, identity information and account history. Information is checked through approved procedures; sending an unrequested document to a person who called or messaged first is not an approved procedure.
Some functions may remain restricted while recovery is open, particularly changes to payment destinations or external connections. This pause can be inconvenient, but it reduces the chance that an attacker uses recovery to redirect value. Once access is restored, review sessions, contact information, connected services and recent activity before resuming normal use.
External connection keys should have only the permissions needed for the intended function. Read access can support monitoring, while trading permission may be needed for a separately chosen automated activity. Withdrawal permission should remain disabled unless a clearly documented service requires it and the client has independently confirmed the arrangement.
Use unique keys, restrict them by network address when the provider supports that control, and rotate or revoke them after suspected exposure. A connection can fail because a permission changed, a provider is unavailable or a credential expired. Do not solve a connection problem by granting every available permission.
Material events such as logins, new connections, strategy changes, notification changes and selected administrative actions are recorded so clients and support can reconstruct what happened. Timestamps may use a stated system time zone, so compare them carefully with local device time when reporting an issue.
An audit record supports investigation but is not an infallible guarantee. Provider logs, device records and payment information may also be needed. Clients should keep their own confirmations and review reports regularly rather than waiting until a dispute arises.
For a suspected compromise, contact [email protected] and identify the message as urgent. Explain what was observed, when it happened and which device or transaction is affected. Support can guide account restriction, session revocation, credential changes and escalation to the appropriate security or compliance team.
Updates are provided as facts become available. Some details may be withheld temporarily to protect an investigation, other clients or legal obligations. We aim to communicate what is known, what action the client should take and when the next update can reasonably be expected.
Cash deposits with a member institution may be eligible for CDIC coverage, subject to its rules. Eligible securities held by a member investment dealer may be covered by CIPF, subject to its limits. Crypto and other digital assets are generally not covered by CDIC or CIPF.
Security controls protect access and data; CDIC and CIPF are separate protection frameworks with specified membership, eligibility and limits. Neither protects against ordinary market losses. Confirm the actual custodian and account structure before assuming that any coverage applies.
Email [email protected] from a safe device. Do not include passwords, one-time codes, recovery phrases or complete payment credentials.
