What Happened During the June 2025 Virtual Office CS Outage?
Customers temporarily lost the ability to access Virtual Office CS applications from the homepage during an approximately four-and-a-half-hour window.
The archived status message states that the problem affected application availability on the homepage between approximately 2:30 a.m. and 7:00 a.m. ET. After service recovered, Thomson Reuters reported that its internal testing showed users could log in, view applications, and launch them normally. The company also said it had stopped receiving new customer contacts associated with the issue.
The public message did not report data loss, confirm that every Virtual Office CS function failed, or disclose the component that caused the interruption.
Incident Record
| Incident detail | Publicly available information |
|---|---|
| Affected service | Virtual Office CS / Software as a Service in the United States |
| Reported symptom | Applications were not available from the homepage |
| Reported window | Approximately 2:30 a.m.–7:00 a.m. ET |
| Resolution | Application viewing and launching returned to a healthy state |
| Publicly disclosed root cause | None located |
| Confirmed data loss | None reported in the public status message |
| Current status | Resolved |
Important Date Clarification
The existing OneUp Networks article identifies the event as occurring on June 12, 2025. However, an archived copy of the Thomson Reuters status entry labels the incident June 11, 2025, while displaying the same 2:30 a.m.–7:00 a.m. ET service window.
The public records therefore contain a date-label discrepancy. This article preserves the existing page and search intent while documenting that inconsistency instead of presenting an uncertain date as independently verified fact.
What Did Thomson Reuters Confirm?
Thomson Reuters confirmed an application-access problem and later confirmed recovery.
The status update supports four conclusions:
- Virtual Office CS applications temporarily disappeared from the homepage.
- The reported incident window lasted approximately four and a half hours.
- Thomson Reuters tested login, application visibility, and application launching after recovery.
- The company moved the incident to resolved status after its metrics appeared healthy and related customer contacts stopped.
These facts establish that a service interruption occurred. They do not establish why it occurred.
What Remains Unknown?
The public status message did not identify the technical root cause, affected infrastructure layer, or remediation details.
The available update does not explain whether the incident involved:
- Homepage application publishing
- Authentication
- User entitlements
- Session delivery
- Network infrastructure
- A deployment or software change
- A third-party service
- Another internal component
It also does not state how many firms or users experienced the problem, whether failover systems activated, or what preventive changes followed the incident.
That distinction matters. A homepage access problem may prevent staff from launching applications without proving that application servers, customer data, or every related service failed.
OneUp Networks should not claim that server overload, Citrix instability, a cyberattack, shared-resource contention, or another platform would have prevented this incident unless evidence supports that conclusion.
Why Should a CPA Firm Preserve Its Own Incident Record?
A firm’s internal evidence can reveal more than a short public status update.
During a disruption, staff often report symptoms in different language:
- “UltraTax disappeared.”
- “The portal is down.”
- “I cannot launch the application.”
- “The login worked, but nothing is available.”
- “It started working again after I refreshed.”
Without a structured record, those reports become difficult to compare. The firm may also lose the information it needs to escalate the problem, evaluate business impact, or decide whether the event affected one user or the entire organisation.
CISA recommends that organisations establish incident roles, preserve relevant logs and artefacts, maintain communication procedures, and exercise continuity plans before a serious disruption occurs.
Virtual Office CS Incident Evidence Log
| Information to record | Example |
|---|---|
| First failed action | Application missing from homepage |
| Exact timestamp and time zone | 6:14 a.m. ET |
| Affected user | User role or internal identifier |
| Affected location | Main office, branch, or remote |
| Scope | One user, several users, or everyone |
| Services tested | Homepage, login, UltraTax, Practice CS |
| Error or symptom | Exact message or screenshot |
| Status-page condition | Operational, investigating, or resolved |
| Support case | Case number and contact time |
| Recovery time | First successful launch |
| Validation completed | Login, open client, print, and e-file checks |
Do not place Social Security numbers, taxpayer documents, passwords, or confidential client data in the incident log.
What Should a Firm Do During a Provider-Wide Incident?
Confirm the scope, protect active work, communicate clearly, and avoid uncontrolled troubleshooting.
1. Assign One Incident Owner
Choose one person to coordinate status checks, support communication, internal updates, and recovery validation. Multiple employees opening separate tickets with different descriptions can create confusion.
2. Confirm the Scope
Test:
- A second user
- A second workstation
- Another office or approved connection
- More than one hosted application
- The official Thomson Reuters status page
Thomson Reuters maintains a dedicated Tax and Accounting Professionals status page for Virtual Office CS/SaaS and other components. The page offers email, text-message, Slack, and webhook subscriptions for incident updates.
3. Preserve Unsaved Work Where Possible
Ask users to stop repeatedly launching applications or making unrelated configuration changes. Record what work was in progress and whether staff had saved it before losing access.
Do not initiate a backup restoration merely because an application is unavailable. Access failure and data loss are different incidents.
4. Protect Deadline-Sensitive Work
Create a list of:
- Returns due that day
- E-files awaiting transmission
- Client approvals still required
- Payroll or accounting deadlines
- Staff whose work has completely stopped
- Tasks employees can continue outside the hosted environment
The goal is not to recreate the full tax workflow manually. It is to identify which obligations require immediate management attention.
5. Send Scheduled Internal Updates
Use one consistent update format:
Current status: Virtual Office CS applications are unavailable from the homepage.
Scope: Confirmed for 12 users across two locations.
Vendor status: Incident reported; investigation or recovery underway.
Next update: 8:30 a.m. ET.
Staff action: Do not repeatedly retry or change local settings. Continue approved offline tasks.
Regular updates reduce duplicate questions and prevent staff from treating rumours as technical conclusions.
How Should the Firm Validate Recovery?
Do not declare the incident over after one person successfully signs in.
Validate the same functions that failed and the workflows the firm needs next.
Recovery Validation Checklist
- Confirm that users can reach the homepage.
- Verify that applications appear for the correct users.
- Launch more than one CS Professional Suite application.
- Open a representative client.
- Confirm that recent work appears intact.
- Test printing or PDF generation.
- Review queued e-filing or workflow activity.
- Check multiple offices or remote locations.
- Record the first successful test time.
- Keep the incident open briefly to watch for recurrence.
The June 2025 status message followed a similar principle by referencing internal metrics, login testing, application visibility, successful launching, and the absence of new related customer contacts before marking the issue resolved.
For missing, deleted, or incorrect data after access returns, use the separate Virtual Office CS backup and restore guide. For slow response rather than lost access, use the Virtual Office CS tax-season performance guide.
Practical Scenario: Access Returns, but the Firm Is Not Ready
Service restoration does not automatically mean business recovery.
Consider a representative 25-person CPA firm. Staff can access Virtual Office CS again after a morning interruption, and management immediately tells everyone to resume work.
Within minutes, the firm discovers that several employees still cannot see UltraTax, one office experiences repeated session failures, and two preparers are unsure whether their early-morning changes were saved.
A safer response would keep the incident open while the IT owner:
- Tests application visibility with representative users.
- Confirms client access and recent data.
- Checks both office locations.
- Reviews urgent e-file work.
- Records unresolved exceptions.
- Releases staff back to normal work in stages.
This approach prevents the recovery process from creating a second wave of confusion.
What Should the Post-Incident Review Examine?
The review should evaluate the firm’s response—not speculate about an undisclosed vendor root cause.
Within two business days, ask:
- How quickly did the firm identify the scope?
- Did staff know where to check official status?
- Who contacted support?
- Did the firm preserve accurate timestamps and screenshots?
- Could staff continue any deadline-sensitive work?
- Did internal updates reach everyone?
- How long did validation take after service returned?
- Did the interruption expose a continuity weakness?
- What should change before the next filing deadline?
CISA recommends maintaining and exercising incident-response, resilience, and continuity plans so critical business functions can continue when technology becomes unavailable.
When Does an Incident Justify an Infrastructure Review?
One historical outage does not automatically justify migration, but recurring or unacceptable business impact deserves evaluation.
| Incident pattern | Appropriate response |
|---|---|
| Isolated incident with limited impact | Document and monitor |
| Repeated access failures | Review incident history and escalation |
| Poor internal communication | Improve the response plan |
| Recovery cannot be validated | Conduct a backup and disaster-recovery review |
| Firm cannot meet continuity requirements | Evaluate alternative architecture |
| Current service repeatedly misses documented needs | Compare hosting and migration options |
A responsible review should examine application requirements, support ownership, recovery objectives, staff locations, integrations, security controls, migration risk, and total cost.
OneUp Networks can assess those requirements without assuming in advance that migration is the correct answer.
Common Incident-Response Mistakes
- Calling every slowdown an outage
- Claiming a root cause before the vendor confirms it
- Allowing every employee to contact support separately
- Failing to record timestamps and time zones
- Restoring data when the problem only affects access
- Announcing recovery after one successful login
- Sending speculative updates to clients
- Using unsupported downtime-cost statistics
- Claiming another platform would have prevented the incident
- Waiting until tax season to assign incident roles
Frequently Asked Questions
The archived status message reports that applications were unavailable from the homepage between approximately 2:30 a.m. and 7:00 a.m. ET, a window of about four and a half hours.
No detailed technical root cause appears in the public incident message reviewed for this article. The update confirmed the access problem and subsequent recovery but did not identify the failed component.
The public status message did not report data loss. Firms should still validate recent work after access returns rather than assume every client and workflow recovered normally.
Thomson Reuters operates a Tax and Accounting Professionals status page that includes Virtual Office CS/SaaS, NetFirm CS, CS Connect, support services, and related products. Firms can subscribe to several notification channels.
Not necessarily. First document frequency, duration, operational impact, recovery quality, and whether the current service meets the firm’s continuity requirements. Migration becomes a reasonable consideration when repeated incidents or architectural limits create unacceptable business risk.
Conclusion
The June 2025 Virtual Office CS incident confirms that customers temporarily lost homepage access to hosted applications and that Thomson Reuters later restored normal application visibility and launching. The available public message does not establish a technical cause, report data loss, or prove that another hosting model would have prevented the event.
The most useful lesson is operational: CPA firms need an incident owner, an evidence log, a communication schedule, deadline triage, and a recovery-validation checklist before the next disruption begins.
OneUp Networks can review your current incident-response and business-continuity process, identify gaps, and determine whether your firm needs better documentation, disaster-recovery preparation, infrastructure changes, or a controlled hosting evaluation. Begin with a continuity and infrastructure review; consider migration or a trial only when the evidence supports that decision.
