Act! Premium v25.1 introduced multi-factor authentication to the desktop edition in 2023. The important historical detail is how that release described the additional factor: Act!'s own documentation specified a numerical verification code delivered by SMS after a user entered a username and password. It did not describe the app-based TOTP setup, QR-code enrollment or one-time recovery-code workflow that some generic MFA explanations attach to every product.
That distinction changes an administrator's rollout plan. An authentication control should be evaluated according to the actual product, version and identity route, not a generic account-security checklist. Act! later announced MFA for Premium for Web v26, and different desktop, web or hosted deployments may have different configuration and recovery requirements. A company preparing a security review in 2026 should confirm its currently supported product and MFA settings rather than treat v25.1 as the newest release.
What the v25.1 control was designed to add
Passwords alone provide limited protection when an employee reuses credentials, falls for a phishing message or has a password disclosed in another system's breach. An additional verification challenge can help prevent an attacker with only the password from signing in. In Act! Premium Desktop v25.1, the published mechanism added a code sent to the user's phone. The specific setup path referenced by the vendor was Tools, then Manage MFA Access, within a supported installation.
A security team should verify this flow with a test account before communicating instructions. Confirm the sign-in screen, the destination of the code, when the challenge is required and what happens if the code is wrong or delayed. Do not assume a QR code, a third-party authenticator app or a particular recovery mechanism exists merely because those features are common in other systems.
This historical capability is a meaningful improvement over passwords alone when deployed correctly. It is not a guarantee of immunity from credential stuffing, account takeover or phishing. An attacker might still control a phone number through SIM swapping, trick a user into disclosing an SMS code or abuse a still-active session. The MFA factor and the identity threat model must be considered together.
Authentication method matters for risk decisions
SMS-delivered codes and phishing-resistant security keys are not interchangeable. An SMS code depends on mobile service, access to the number and the integrity of the user's sign-in process. A user can be persuaded to relay a code, and an adversary who compromises the phone account may receive messages. These risks do not make SMS MFA useless; they explain why policy should not describe it as the strongest available form of authentication.
The more general subject of multi-factor authentication includes several distinct methods, each with different usability and attack-resistance properties. Administrators should document exactly what their Act! deployment supports. If the company's identity standard requires phishing-resistant MFA, verify whether the CRM login route and any connected identity provider can meet that rule; do not simply check a box marked MFA and assume compliance.
A login challenge also protects only the identities and sessions in its scope. An integration that uses a separate database connection, API token, service account or legacy client may need independent controls. Review administrator access, scheduled tasks and external connectors in addition to interactive employee sign-ins.
A rollout decision should distinguish user education from a security exception. A person who cannot receive an SMS code because a number has changed needs a verified recovery route, not an informal permanent bypass. If the product or selected deployment cannot meet an organization's identity policy, document the gap and assess supported alternatives rather than weakening the control for convenience. Test access on the same network and operating environment used by staff, because a demonstration on an administrator's workstation may not reveal the restrictions affecting remote users or field employees.
Rollout starts with account and device ownership
Before enforcing a second factor, identify how users receive business SMS messages and what happens when a phone number changes. A shared office mobile, an employee's personal number and a company-managed handset may raise different privacy and recovery concerns. The organization should have a documented policy for enrollment, number changes, temporary access and an employee's departure.
Begin with a small number of noncritical test accounts covering ordinary users and privileged administrators. Verify successful sign-in, incorrect-code rejection, code expiry or replay behavior according to the actual implementation, and the ability to revoke access after an account is disabled. If an administrator cannot confirm a behavior from the product and test environment, mark that question as unresolved rather than inventing a control.
Training should tell employees where legitimate challenges appear and why they must never share a verification code with a caller or support impersonator. Help-desk staff need an identity-verification process before changing a registered phone number. Otherwise the reset channel can become a weaker path around the additional factor.
Lost phones and account recovery are security events
A lost phone is an operational interruption, not just a routine login inconvenience. A user must have an approved way to prove identity and regain access without allowing an attacker to replace the registered phone number. The organization should identify the exact recovery procedure supported by its Act! version and keep the procedure separate from assumptions about authenticator apps or single-use backup codes.
Test recovery during a planned exercise with a test account, including temporary loss of mobile coverage. Confirm who is authorized to reset enrollment, how the action is recorded and whether privileged users require additional verification. A recovery process should produce an audit trail or other evidence appropriate to the system's capabilities and the company's security policy.
Do not promise that Act! v25.1 generates a set of recovery codes if the vendor materials used for the deployment do not support that claim. Similarly, avoid claiming that all failed MFA attempts automatically feed a security information and event management platform. Logging and integration capabilities must be verified on the deployed product and configured connectors.
MFA complements permission and data controls
A strong login process cannot prevent an authorized but excessively privileged employee from viewing customer information unrelated to the job. Review record-sharing permissions, administrator roles, export options, customer attachments and the access granted to integrations. A properly authenticated session can still expose too much data if role design is weak.
The same principle applies to customer data retention. Additional verification does not define which records may be stored, how long they are retained or when an account should be disabled. Financial, health-related or other sensitive information should be handled according to the organization's documented policies, not a blanket statement that using MFA automatically makes the CRM compliant with a specific regulation.
Security testing should include a user transferred to another team, a disabled employee, an administrator with an expired account and a contractor who should see only assigned records. Test how each state affects desktop access, web access and connected tools. Different login pathways can create gaps even when the primary application shows an MFA prompt.
A monitoring team may also want to know whether repeated failed login attempts and suspicious resets can be investigated. That requirement should be documented before deployment, but the availability of usable sign-in logs, alerting and external log export must be established from the precise Act! installation. Where a legacy product cannot provide the evidence needed by organizational policy, a surrounding identity or network control may need to supply that capability. Do not write that the CRM automatically generates complete centralized audit events without a tested data source. Equally, if staff use the Act! Sidebar for Outlook introduced in v25.2, evaluate its authentication and record-permission path separately; the desktop v25.1 sign-in announcement does not prove the later Outlook connection inherits every security control.
An additional risk is the administrative assumption that MFA protects data in every state. It protects a login route, not customer exports sent to an outside recipient or a local database copy left unsecured. Review data encryption, storage permissions, backups and staff access alongside the authentication configuration. A responsible security assessment should document both what the extra factor prevents and what remains possible after a successful sign-in.
Read historical release claims in the correct edition
Act! v25.1's desktop announcement was followed by later release changes, including Premium for Web v26 MFA. That chronology matters: a company may have one feature in a locally installed environment but a different authentication route in a web or cloud environment. A product article from 2023 is not a promise about license coverage, setup steps or supported protocols in November 2026.
For an upgrade, first document the edition, version, hosting model and current vendor support status. Then map the required sign-in and recovery behaviors to what the product actually provides. Test the result across all user roles, and record any noninteractive integrations that do not follow the human login flow.
The strongest outcome is not the greatest possible number of verification prompts. It is a credible security design in which access is granted only to the intended person, problems are recoverable through a controlled process and authentication is supplemented by correct permissions, device hygiene, backup and monitoring. v25.1 marks an important point in Act!'s security history, but present-day protection depends on the actual, verified deployment.
