Abrigo kept Sageworks offline about 69 hours; its status page says only "irregular activity"

68 hours 46 minutes, and one sentence on cause

Abrigo says it disabled its Sageworks lending and risk platform at "approximately 11:25am ET" on Friday 30 October 2026. Its status page says the platform was available again at 07:11 EST on Monday 2 November, except for "borrower facing capabilities". That is 68 hours 46 minutes (derived from the printed times). Across nine status entries in that time, the only sentence about cause is this one: "We identified irregular activity in our environment, and, out of abundance of caution, we disabled the Sageworks application at approximately 11:25am ET."

What that does not establish is almost everything a lender needs. The page does not say whether the cause was an attack or a fault, when the activity began, what data or credentials it touched, how many institutions are affected, whether police or a forensic firm are involved, or when the borrower facing features return. An outage is not proof of a breach, and it is not proof that there was none. "Irregular activity" is a label, not a finding.

This briefing rests on Abrigo's own pages, read about 21:01 to 21:08 UTC on Monday 2 November 2026: the incident entry and overview on its status page, a 2022 post on its blog about bank incident notification rules, and three pages of its developer documentation. One secondary report, from BleepingComputer, is used for context and is marked as secondary wherever it appears. At the last read, 21:08 UTC, the newest status entry was still the one posted at 07:11 EST on 2 November, 8 hours 56 minutes earlier (derived). Any later entry will overtake parts of this page.

What the nine status entries say

The incident entry on Abrigo's status page is titled "Sageworks Analysis, Sageworks API and Online Portal Now Unplanned Maintenance." Its affected services are listed as Online Portal Now, Sageworks Analyst and Sageworks API. The page's history view still listed it as an unresolved incident when read. The first entry, at 10:58 EDT on 30 October, calls it "emergency maintenance" and apologises for the late notice. The words irregular activity first appear at 13:27 EDT, 2 hours 29 minutes later (derived). Every later entry says the team continues to investigate, gives a time for the next update, or reports the restore.

Zoom

Two cautions on that second table. The status page is one channel; Abrigo says notices also go by email to institutions' contacts, so the late posts may not mean late emails. And the stated disable time is "approximately", so the 27 minute gap with the first post is a reading of two printed times, not a finding. Both are things a lender can check against what it was sent.

Labels that are not findings

Several words on the page do the work of an answer without being one. Emergency maintenance, and the incident title's Unplanned Maintenance, describe what the vendor did to the system, not why. "Irregular activity" names no actor and no action. "Out of abundance of caution" says the decision to disable was precautionary; it does not say what was feared. The 20:03 EDT entry on 30 October carries the status label Identified, yet its text only says the team "continues to investigate". On this page the label is the platform's workflow stage, not a statement that anything has been identified.

The restore wording needs the same care. "Now available" describes service, not security: it does not say the activity has been contained, that credentials were reset, or that the cause is closed. The final entry, "continuing to monitor for any further issues", is the vendor's own hedge. Restored is not contained.

One more entry sits on the same page and is not tied to this incident by anything it prints: a notice from 21 October titled "Emergency Construct Maintenance", described as a security update to a different Abrigo product, Construct. This site draws no link between the two.

What one outside report adds, and what it cannot

BleepingComputer published on 2 November (its page data gives 14:00 US Eastern). This site read it in full and treats it as secondary. It says Abrigo serves "more than 2,400 entities" among community banks and credit unions in the United States, describes Sageworks as a platform for processing loan applications, analysing borrowers' finances and monitoring loan portfolios, and says it asked Abrigo for details and had no reply by publication. It adds that until the nature of the incident is disclosed, it is unclear whether a breach or a technical issue caused the outage. That is a fair reading of the status page too.

Two things in that report are not in Abrigo's entries, and this site cannot confirm either. It says Abrigo detected suspicious activity earlier on 30 October; the status page gives no detection time, only the disable time. And it recalls an unconfirmed claim made earlier this year by someone said to belong to an extortion group, about Abrigo records held in Salesforce. The report itself says no breach has been confirmed. That claim is a third party's allegation, it is not evidence about this outage, and no source read here links the two. The same report says some researchers advised banks and credit unions to rotate the API keys for the Sageworks platform; it does not name them or say what that advice rests on.

A note on names: the status page's incident title says Sageworks Analysis, while its list of affected services says Sageworks Analyst. This briefing uses the services list, as the outside report does.

Where the platform sits, and which keys it holds

Zoom

The lender holds the regulator relationship and the borrower relationship; the hosted platform, as the outside report describes it, handles loan applications and borrowers' finances. The one connection Abrigo documents in public is the programmatic one. Its developer documentation says that once an institution has an API subscription, credentials "can be self-issued from within your Sageworks account", with a scope chosen by the lender, and that the client ID and secret are to be stored securely. The authentication page describes a standard token request and a short lived access token. The FAQ says the Sageworks API goes through an identity provider built on OAuth 2.0.

That matters because the credentials sit in two places: with Abrigo, and in whatever lender system uses them. Abrigo's entries do not say whether any credentials were involved, so a lender cannot tell from them which side, if either, needs to change. The documentation does not describe revoking or rotating a client, so that is a question for the vendor.

What Abrigo's own 2022 post says about notice duties

Abrigo's blog carries a guest column of 6 April 2022 by two lawyers at Mayer Brown on United States rules for incident notification. It is background, not a statement about this outage. As the column describes the rules for banks, a service provider must tell each affected institution "as soon as possible" after it determines it has had a computer security incident that has materially disrupted or degraded, or is reasonably likely to, covered services for four or more hours. The notice may go to a contact the institution has designated. The column defines a computer security incident as "an occurrence that results in actual harm to the confidentiality, integrity, or availability" of an information system or its information, and says regulators have stressed that this can include non malicious occurrences such as hardware or software failure.

Read against this outage, the arithmetic is plain and the law is not. The outage ran about 17 times the four hour threshold (derived: 68.8 hours against 4). But whether this was a computer security incident in the rule's sense is exactly what Abrigo has not said, and the rule's wording is about the provider's determination. Abrigo's statement that notices go to each institution's Product and IT & Security contacts is at least consistent with the designated contact idea in the column.

For the lender, the column describes a separate clock: a bank must notify its federal regulator as soon as possible and no later than 36 hours after it determines that a notification incident has occurred. The column says its definition of a covered financial institution does not include credit unions, and this site did not read the rules that apply to them. State law, contract terms and other regulators add more. None of this is legal advice; it is the reason to put the dates and the vendor's words in front of counsel now.

What a lender can do, in order

Technical details

Abrigo's status entries print no indicators, no versions, no hashes, no addresses and no technique, so there is nothing to hunt for in a lender's logs from the vendor's text, and this site has not invented any. What Abrigo's public developer documentation does print is how a lender creates and uses an API client. A defender can use it to build the inventory in step three of the checklist and to know what a normal token request looks like. The path below is where the documentation says a lender issues credentials in its own Sageworks account. Use it to find the clients that already exist.

Gear icon -> Third-Party Connections -> Abrigo APIs -> Add New

The authentication page prints the token endpoints for three environments and the shape of the request and response. The values in square brackets are the documentation's own placeholders, not credentials. A lender that logs outbound traffic can recognise these hosts and the client credentials grant, and can check which of its systems call them, and from where.

Production = https://auth.sageworks.com/connect/token
UAT = https://uatauth.sageworks.com/connect/token
Sandbox = https://sandboxauth.sageworks.com/connect/token

Request Body
{
 "client_id": "[your-client-id]", 
 "client_secret": "[your-client-secret]", 
 "grant_type": "client_credentials" 
}

Response Body
{
 "access_token": "[your-bearer-token]", 
 "expires_in": 900, 
 "token_type": "Bearer" 
}

The documentation's FAQ also prints the API's published rate limits, which give a baseline for what unusual volume looks like on a lender's own client:

100 API calls per minute per endpoint. 1000 API calls per hour per endpoint.

The question the entries leave open

Abrigo has told its customers, in effect, that something irregular happened, that it switched the platform off, and that most of it is back. The question to put to the vendor, and to your own board, is this: if the answer to "was borrower data or any credential involved" is not in writing by the time your own notification clock would have started, what will you have decided without it?

Key facts