Active Directory Security Assessment for Banks: Examiner Expectations, Real Cost, and the Findings That Reach the Wire Room
Alexander Sverdlov
Security Analyst
Key Takeaways
- A defensible AD security assessment for a community bank with a single charter, up to 1,500 domain accounts, and one or two domain controllers sits in the USD 7,500 to USD 14,000 band and ships a written report with examiner-ready evidence in 12 to 16 business days. Regional multi-domain banks run USD 16,000 to USD 28,000. Multi-charter holding companies typically run USD 30,000 to USD 52,000
- Four bank-specific AD findings repeat on nearly every financial institution forest we assess: service accounts wired into Fiserv, Jack Henry, or FIS platforms with passwords that have not changed since initial deployment; a domain trust from a prior acquisition with Domain Admin-equivalent paths still alive; a vendor or MSP RMM agent running under a standing Domain Admin account; and wire-room jump hosts that are reachable from a standard teller workstation via a single BloodHound path
- FFIEC examiners, NYDFS Part 500 reviewers, and NCUA IT examination teams have all aligned on privileged access controls as a top finding category this year. An AD assessment that maps findings directly to FFIEC CAT Domains, GLBA Safeguards Rule sections, and NYDFS Part 500 sections satisfies the evidence burden for a safety-and-soundness exam and closes an MRA with a single deliverable
- The path from a phished teller workstation to Domain Admin to the core banking system executes in under 90 minutes on the average community bank forest we assess. The path from Domain Admin to the wire room is a further 20 to 40 minutes in environments where jump-host access is not gated by a separate Tier 0 credential. The fix closes 70 to 85 percent of BloodHound attack paths in a single 4-hour Saturday change window
- Three open-source tools (PingCastle, BloodHound CE, PurpleKnight) plus a manual review of core-platform service accounts and RMM agent permissions cover the technical spine. The differentiated value for a bank is the regulatory mapping layer: each finding cross-referenced against FFIEC CAT, GLBA, NYDFS, NCUA, and SOX IT general controls so the examiner evidence package is ready on delivery day
- A quarterly retainer priced at USD 24,000 to USD 72,000 per year (depending on charter scope) aligns exactly with the examination cadence that FFIEC-supervised institutions face and gives the board and the qualified individual under the GLBA Safeguards Rule a continuous attestation posture rather than a single annual snapshot
The call came in late on a Tuesday in February. The Chief Information Officer of a USD 1.2 billion-asset community bank in the Mid-Atlantic region was forwarding an email from their OCC examiner. The examiner had issued a draft Matter Requiring Attention (MRA) citing weaknesses in privileged access management and identity governance. The specific language read: "The institution has not conducted an independent review of privileged access controls within the Active Directory environment, and management cannot demonstrate that service accounts connected to the core banking platform are governed by a formal access review process." The MRA was not yet final. The bank had 45 days to submit a corrective action plan, and the examiner expected documented evidence of an independent assessment to be included.
The CIO had three problems. First, nobody on the IT staff had run BloodHound or PingCastle on the forest in any documented form. Second, the bank had acquired a smaller credit union two years earlier and the acquired institution's domain forest was still live, still trusted by the production domain, and still contained 14 service accounts from the credit union's old core banking platform that had not been deprovisioned. Third, the bank's managed service provider had a standing Domain Admin account in the production forest that the MSP used for its remote monitoring and management (RMM) platform, and the bank had no documented process for reviewing or limiting that access.
We scoped a 14-business-day assessment at USD 12,800 fixed price. One production forest, two domains (production plus the acquired credit union stub), 6 domain controllers, 1,640 user accounts, 3,900 computer accounts. The deliverable was a written findings register with 28 items ranked Critical to Informational, a BloodHound attack-path graph showing 11 paths from a standard teller account to Domain Admin, a regulatory mapping table cross-referencing each finding against FFIEC CAT, GLBA Safeguards Rule, and NYDFS Part 500, a 60-day remediation plan, and an attestation letter the OCC examiner accepted as part of the corrective action package. The MRA was closed as a repeat-examination track item at the 45-day mark.
Below is what was inside that engagement, the regulatory framework that makes AD assessment a compliance obligation for every federally supervised bank and credit union, the bank-specific findings that examiners and insurers consistently flag, and the pricing paths that work for community banks, regional banks, and holding companies without funding a permanent consulting dependency.
Section 1
Why Active Directory Is a Bank-Specific Risk Problem, Not a Generic IT Problem
A mid-market manufacturer that suffers a domain compromise faces ransomware, data theft, and production disruption. A bank that suffers a domain compromise faces all of those outcomes plus a direct path to wire fraud, ACH manipulation, FedLine credential theft, and core banking system access that can authorize transactions worth millions of dollars in under 30 minutes. The threat model is different, the blast radius is different, and the regulatory obligation to address it is explicit and examiner-verifiable in a way that most other industries simply do not have.
The core banking platform - whether it runs on Fiserv DNA, Jack Henry Silverlake, FIS IBS, Temenos Transact, or a legacy in-house system - authenticates to the production Active Directory for its service accounts, its operator workstations, and in many cases its administrative interfaces. The wire room connects to SWIFT, FedLine Direct, FedNow, or a third-party wire origination platform through workstations that sit on the same domain-joined infrastructure as teller PCs. The ACH origination system is typically running on a domain member server with a service account whose password was set at deployment and has not changed since. The segregation of duties between the person who enters a wire and the person who approves it is enforced in the core platform, but that enforcement collapses entirely if an attacker has Domain Admin access, because they can reset the approving officer's password in 8 seconds and perform the approval themselves.
This is not a theoretical risk. The FBI IC3 reports released over the last four years document dozens of community bank wire-fraud incidents where the initial foothold was a phished back-office employee, the pivot to Domain Admin took under two hours via Kerberoasting or unconstrained delegation, and the attacker-authorized wire transfer occurred within 24 hours of the initial compromise. In several documented cases the attacker sat in the domain for 60 to 90 days before executing the fraud, using that time to map the wire authorization workflow and identify the accounts that controlled it.
The AD assessment for a bank must therefore do two things simultaneously: produce the technical findings register that closes the BloodHound attack paths, and produce the regulatory evidence package that satisfies the examiner. Those two deliverables share most of the underlying work but require different framing. The examiner does not need a BloodHound graph; they need a statement of scope, a list of findings tied to specific control categories, and an attestation that an independent qualified party performed the assessment. The CIO needs both.
A note on scope. An AD assessment for a bank is not a core banking platform security review and it is not a FedLine Direct security assessment (though the latter is a FRBSF-required annual self-assessment). It is a focused review of the Windows identity infrastructure that everything else sits on. If the domain is compromised, the controls inside the core banking platform, the wire origination system, and the ACH processor are irrelevant. The AD assessment is the floor below which every other control is built.
Section 2
The Regulatory Stack: FFIEC, GLBA, NYDFS, NCUA, OCC, and SOX IT General Controls
No other industry outside defense contracting faces a regulatory overlay as dense and examiner-enforceable as banking when it comes to identity and access management. Understanding which regulation says what is the foundation of an examiner-ready AD assessment deliverable.
FFIEC Examination Expectations and the Cybersecurity Assessment Tool
The Federal Financial Institutions Examination Council (FFIEC) does not mandate a specific AD assessment standard, but its IT Examination Handbook (Information Security booklet, updated in recent years) and the FFIEC Cybersecurity Assessment Tool (CAT) create an expectation matrix that examiners use during safety-and-soundness IT examinations. The CAT's Architecture and Operations domain (Domain 2) explicitly covers access management, including privileged access controls, service account governance, and the separation between privileged and non-privileged credentials. An institution whose AD posture has never been independently assessed will struggle to demonstrate maturity above the CAT's Baseline level on Domain 2, which translates directly to examiner findings and corrective action plans.
GLBA Safeguards Rule - Access Controls and the Qualified Individual
The Gramm-Leach-Bliley Act Safeguards Rule (16 CFR Part 314), amended with requirements that took effect in the recent years, requires covered financial institutions to implement access controls as part of an information security program and to designate a "qualified individual" responsible for overseeing and implementing the program. Section 314.4(f) specifically requires access controls including multi-factor authentication for anyone accessing customer information systems. Section 314.4(i) requires periodic monitoring and testing. An AD assessment that identifies stale privileged accounts, weak service account passwords, or missing MFA enforcement on domain controller administrative interfaces is directly responsive to Safeguards Rule compliance obligations. The qualified individual is now personally accountable for reporting to the board at least annually on the program's status - making the AD assessment findings register a board-level document.
NYDFS 23 NYCRR Part 500
For New York-chartered banks and any covered entity under the Department of Financial Services' jurisdiction, 23 NYCRR Part 500 is the most prescriptive privileged access regulation in the United States. Section 500.7 requires MFA for any individual accessing internal networks from an external network. Section 500.7(b) specifically requires MFA for privileged accounts. Section 500.16 requires a documented audit trail for cybersecurity events. Section 500.3 requires a cybersecurity program that addresses, among other things, access controls and privileged access management. An AD assessment finding that a privileged account is accessible without MFA from a workstation on the internal network is a direct Part 500.7(b) gap; an examiner who sees it will issue an MRA or consent order.
NCUA for Credit Unions
The National Credit Union Administration (NCUA) conducts IT examinations using the ACET (Automated Cybersecurity Examination Tool), which is the NCUA's version of the FFIEC CAT adapted for credit unions. Domain 5 of the ACET covers Cyber Controls and includes privileged access management as a primary focus area. NCUA examiners at state and federal credit unions have increased their focus on identity infrastructure over the last two examination cycles. Credit unions that have completed mergers (the equivalent of bank acquisitions) and carry inherited domain forests are a specific examiner focus point, given the documented incidents involving legacy access paths from absorbed institutions.
SOX IT General Controls for Publicly Traded Banks
Publicly traded banks and bank holding companies file under the Sarbanes-Oxley Act, which requires management to assess the effectiveness of internal control over financial reporting (ICFR). IT general controls (ITGCs) are a foundational layer of ICFR: they include logical access controls to systems that process, store, or report financial data. An AD finding that a terminated employee's domain account (or an acquired bank's stale service account) has write access to a financial reporting application is a direct SOX ITGC deficiency. External auditors testing ITGCs will ask for evidence of access reviews, privileged access management, and periodic assessments. An AD assessment deliverable with a regulatory mapping table gives the external audit team the evidence they need in the format they expect.
Examiner tip: Map every finding in your AD assessment register to at least one regulatory citation before submitting it as evidence. Examiners are not required to make the mapping themselves. A findings register that says "Finding 4: Unconstrained delegation on COREAPP01 - exploitable in approximately 12 minutes by any authenticated domain user - maps to FFIEC CAT Domain 2 Baseline control B.CC.3 and GLBA Safeguards Rule 314.4(f)" closes questions faster than one that simply lists a technical finding without regulatory context.
Section 3
Bank-Specific AD Findings: Core Platform Service Accounts, MSP Access, and Wire-Room Paths
Generic AD findings (Kerberoastable accounts, unconstrained delegation, stale Domain Admins) appear in bank forests just as they appear in manufacturer and logistics forests. But banks carry additional finding categories that are specific to their technology stack and operational model. These are the ones that generate MRAs.
3.1 Core banking platform service accounts
Every major core banking platform - Fiserv DNA, Fiserv Premier, Jack Henry Silverlake, Jack Henry Banno, FIS IBS, FIS Modern Banking Platform, Temenos Transact - uses one or more Active Directory service accounts for its application services, scheduled tasks, database connections, and administrative interfaces. These accounts are almost always password-based (not gMSA-eligible without platform vendor validation, though many platforms now support gMSA on current versions). In every bank forest we assess, at least one core platform service account has a password that has not changed since the platform was deployed or since the last major version upgrade. In several cases the password was set by the implementation engineer during the initial deployment and was never changed because the bank's IT staff did not know the service account existed or did not have documented credentials to manage it. A Kerberoastable service account with a password set in a prior year and a 20-character or shorter password is crackable in under 4 hours of offline GPU time for roughly USD 40 of cloud GPU cost. When that account has permissions in the core banking application - which it typically does, because it runs the application - that crack is a core banking access event.
3.2 MSP and vendor RMM standing Domain Admin access
Community banks overwhelmingly rely on managed service providers for their day-to-day IT operations. The MSP's remote monitoring and management (RMM) agent - whether it runs on ConnectWise, Kaseya, N-able, Datto RMM, or a similar platform - typically authenticates to domain-joined endpoints using a domain account. In nearly every community bank forest we assess, that account is a member of Domain Admins. It has a static password (MSP RMM platforms do not support gMSA natively without custom integration). It is never reviewed as part of the bank's quarterly privileged access review because it is treated as a vendor account that the MSP manages. And it is reachable from the MSP's management plane, which means a compromise of the MSP - or of a single MSP technician's credential - is a compromise of the bank's domain. The FFIEC has specifically flagged third-party access management as a recurring finding category in its most recent examination cycles. The fix is not to eliminate MSP access; it is to replace standing Domain Admin with a JIT (just-in-time) privileged access workflow where the MSP account has no persistent elevated access and must request a time-limited elevation via a PAM tool that the bank controls.
3.3 Wire-room jump host isolation gaps
The wire room in a community bank is typically 1 to 3 dedicated workstations that connect to the wire origination interface (FedLine Desktop, a third-party wire platform, or the wire module inside the core banking system). In the majority of bank forests we assess, these workstations are domain-joined to the production domain, sit in the same OU as teller workstations, and have no additional network-layer controls preventing lateral movement from a compromised teller PC. BloodHound routinely shows a path from a teller account to a wire-room workstation via a shared local administrator credential (LAPS is not deployed), a GPO misconfiguration, or an over-provisioned helpdesk account. The fix is a combination of controls: LAPS on every workstation including wire-room machines, a dedicated OU with a restrictive GPO, network segmentation at the VLAN level, and MFA on the wire origination login that is enforced at the application layer rather than just the domain. None of these controls is expensive; all of them require a change window and a test plan.
3.4 Acquired-bank forest trusts
Bank M&A creates domain trust debt. When a community bank acquires a smaller bank or credit union, the acquired institution's AD forest typically remains live during an integration period that can range from 6 months to 3 years. A bidirectional trust is established to allow single sign-on for the combined employee base. The trust usually outlives the integration project because deprovisioning it requires a hard cutover of every account in the acquired domain, which IT staff deprioritize relative to other migration tasks. In every bank with a recent acquisition we have assessed, the acquired domain still contained service accounts with elevated permissions in the acquiring bank's forest - permissions granted during the integration period and never revoked. SID filtering was off on the trust in 4 of the 6 acquired-bank trust configurations we have reviewed this year, meaning any account in the acquired forest with a matching SID could inherit permissions in the acquiring forest without an explicit ACL grant.
Finding observed at a USD 1.2 billion-asset bank: An acquired credit union's IT administrator account - disabled in the acquired domain but still present in the acquiring bank's Domain Admins group via the trust - was reachable from the production forest because SID filtering was off. The account's password had not been changed in three years. It was Kerberoastable. A BloodHound query showed it could reach the wire-room jump host in two hops. The fix was a 90-minute change window: enable SID filtering on the trust, remove the account from Domain Admins, disable it in the acquired domain, document the gap in the corrective action log. The examiner accepted the fix as responsive to the MRA and closed the finding at the 45-day mark.
The pattern extends to dual-control and segregation-of-duties failures in privileged groups. Banks are required under Regulation E, their own internal policies, and in many cases OCC guidance to maintain dual control over wire authorization. If the same domain account can both initiate and approve a wire in the core platform's application layer, that is an application control failure. But if a single Domain Admin credential can reset the password of both the initiator and the approver role in the application, the dual control is bypassed at the identity layer, and no application-layer control can prevent it. We document this finding as a combined technical and governance gap on every bank engagement where it appears.
Section 4
Technical Spine: PingCastle, BloodHound CE, PurpleKnight, and Manual Core-Platform Reviews
The three standard AD assessment tools cover the same ground in a bank forest that they cover everywhere else - with one critical addition. Bank forests require a manual layer of analysis that the tools cannot automate: the review of service accounts connected to core banking platforms and the mapping of those accounts against the platform vendor's current supported configuration.
PingCastle will flag a service account as Kerberoastable if it has an SPN and a password older than a configurable threshold, but it does not know that the account runs the Fiserv DNA application server, that the password was set by a Fiserv implementation engineer during a deployment engagement, or that rotating it without coordination with the Fiserv support team will bring down the core banking platform at 9:00 AM on a Monday. That context is discovered in the manual service account inventory, not in the tool output. The remediation plan for a core platform service account is therefore always a coordinated change, not a simple password reset - and it is documented accordingly in the bank-specific findings register.
BloodHound CE's value in a bank forest is the same as everywhere: the attack-path graph from a starting node (a phished teller account, a compromised MSP technician credential, a vendor workstation on the guest VLAN that managed to reach a domain-joined system) to a Tier 0 target (Domain Admin, a domain controller, the Exchange hybrid connector, the wire-room jump host). In a bank forest, the Tier 0 targets are extended to include the wire-room workstations, the core banking application server's administrative interface, and any system that can authorize ACH or wire transactions. BloodHound does not natively understand "wire-room OU" as a Tier 0 target - that designation is applied manually during the assessment by tagging those systems as High Value Targets in the BloodHound CE interface, which changes the path analysis output accordingly.
PurpleKnight complements PingCastle with a more recent indicator set. In bank forests we have seen PurpleKnight surface DCSync rights granted to the core banking application service account (an artifact of a vendor deployment script that granted it Replicating Directory Changes permissions because it was convenient at implementation time), Group Policy preferences containing a cpassword attribute on a teller workstation GPO (meaning any authenticated domain user can decrypt the local admin password set by that GPO), and RBCD misconfiguration on the load balancer serving the core banking web UI. In 4 of the bank forests we have assessed this year, PurpleKnight produced at least one Critical finding that PingCastle classified as Informational or did not surface at all.
| Tool / Method | Cost | What it covers in a bank forest | What it cannot replace |
|---|---|---|---|
| PingCastle Basic | Free | Posture score, trust configuration, account hygiene, ~100 rules | Attack-path graph, core-platform context |
| BloodHound CE | Free | All privilege-escalation paths including wire-room HVT tagging | Written report, regulatory mapping |
| PurpleKnight | Free | Modern IOCs, DCSync grants, cpassword, RBCD edge cases | Attack-path visualization, vendor context |
| Manual core-platform SA review | Assessor time | Fiserv/JH/FIS SA inventory, gMSA eligibility, rotation coordination | Cannot be automated - requires vendor docs |
| Regulatory mapping layer | Assessor time | FFIEC CAT, GLBA, NYDFS, NCUA, SOX ITGC citations per finding | Cannot be automated - requires regulatory expertise |
If an AD assessment vendor for a bank produces a report that is only PingCastle and BloodHound output without a manual core-platform service account inventory and without a regulatory mapping table, push back before sign-off. The examiner will push back harder at the next examination cycle.
Section 5
What the Bank AD Assessment Deliverable Must Contain to Satisfy an Examiner
The deliverable for a bank AD assessment serves two audiences: the IT team that has to execute the remediation and the examiner who has to accept the evidence package. Most AD assessment reports serve one audience or the other. A bank-grade deliverable must serve both simultaneously, and the structure has to be deliberate about that.
First, an executive summary written for the board and the qualified individual. Two pages. Plain English. The headline numbers: how many Critical findings, how many High, how many BloodHound paths to Domain Admin from a teller workstation. A single paragraph on the most significant finding - typically the core platform service account Kerberoasting scenario or the MSP standing Domain Admin - that explains the business risk in terms a non-technical board member can understand (for example: "An attacker who compromises any domain account can steal the credential used to run the core banking platform's transaction service within approximately 2 hours using a widely available cracking tool, after which they have the permissions of the application itself inside the core banking system"). A clear directive: address the three Critical findings before the next examiner contact; schedule the High findings within 30 days.
Second, a findings register with regulatory mapping. One row per finding. Columns: finding ID, severity (Critical / High / Medium / Low), affected object, exploit description, estimated exploit time, regulatory citation (FFIEC CAT control ID, GLBA section, NYDFS section, or NCUA ACET domain as applicable), recommended remediation, owner role, target close date, and actual close date (filled in during the re-test pass). A defensible register for a community bank forest with 1,500 accounts typically runs 20 to 35 rows.
Third, a BloodHound attack-path chapter. Generated from BloodHound CE. The bank-specific version tags wire-room workstations, the core banking application server, and any ACH or wire origination system as High Value Targets in addition to the standard Tier 0 targets. Annotate each path with the starting node (for a bank, use role-based node labels: "Teller workstation," "MSP RMM agent," "Vendor access workstation"), the pivot points, and the ending node. Estimate attacker time per path. For the highest-severity path - the one that reaches a wire-room workstation or a core banking admin interface - include a narrative description that non-technical readers, including the examiner's team, can follow.
Fourth, a written remediation plan. The first 14 days address the Critical findings. Days 15 through 30 address the High findings. Days 31 through 60 address the Medium findings. For each task: owner role, estimated effort, test plan (how do we verify the fix closed the finding), and a note on any coordination required with a core platform vendor or MSP. The remediation plan must be executable by the bank's IT staff with defined external support rather than an open-ended consulting engagement.
Fifth, the attestation letter. One page, signed by the assessor, addressed to the board and the qualified individual. States the scope (which forests, which domains, which tool versions, which assessment framework), the dates of work, the number of findings by severity, the highest-risk finding in a single sentence, and a statement that the assessment was performed independently and objectively. The examiner will read this letter first. It must be concise, unambiguous, and signed. An attestation letter that says "we ran the tools and here is the output" is not an attestation; it is a cover page.
Examiner evidence checklist for a bank AD assessment: (1) attestation letter from a named qualified assessor with date and scope; (2) findings register with regulatory citations per finding; (3) BloodHound attack-path graph with wire-room and core-platform HVTs tagged; (4) remediation plan with target dates and owner roles; (5) evidence of Critical finding remediation (change tickets, before/after PingCastle scores, BloodHound delta showing path closure); (6) board or qualified individual sign-off on the report. An examiner who receives all six items typically closes the associated MRA at the next examination cycle without additional follow-up.
Section 6
Pricing Tiers for Community Banks, Regional Banks, and Multi-Charter Holding Companies
Bank AD assessment pricing follows three honest tiers, each scoped to the complexity of the institution's charter structure and domain environment. Below is the model we run, drawn from bank and credit union engagements over the last 18 months. These figures are all-in fixed-fee prices for the assessment, the findings register with regulatory mapping, the BloodHound attack-path report, the remediation plan, and the attestation letter. Remediation support beyond the included re-test pass is scoped and priced separately.
The quarterly retainer model deserves special emphasis for regulated institutions. A quarterly cadence - four assessments per year, each producing an updated findings register, a BloodHound delta showing path reduction, and a refreshed attestation letter - aligns exactly with the examination rhythm that FFIEC-supervised institutions face. The board and the qualified individual get a continuous posture trend line rather than a single annual snapshot. Annual retainer pricing for a Community Bank tier runs USD 24,000 to USD 32,000. Regional Bank quarterly retainers run USD 40,000 to USD 60,000 per year. Multi-charter holding companies typically run USD 72,000 to USD 110,000 per year, split across per-charter evidence packages that each examiner team can review independently.
The remediation budget is separate from the assessment cost. The median external remediation support budget across bank engagements is USD 8,000 to USD 12,000 for Community Bank tier (typically 40 to 60 hours of identity engineering time, focused on gMSA migration for core platform SAs and JIT access workflow setup for the MSP), USD 16,000 to USD 24,000 for Regional Bank tier, and USD 32,000 to USD 55,000 for Holding Company tier. Internal IT staff time typically runs 80 to 200 hours per forest for the actual configuration changes, change window execution, and test plan verification.
Section 7
60-Day Remediation Plan and Examiner Evidence Timeline for Banks
The remediation plan for a bank AD assessment is structurally similar to the generic 60-day plan, but with two critical differences: the sequencing must account for core banking platform change management (typically a 2-week change freeze window around quarter-end), and every completed task must produce evidence that is suitable for an examiner evidence package. Change tickets, before/after screenshots, and re-test delta reports are not optional for a bank - they are the substance of the corrective action package.
Day 1 of the bank remediation plan carries the same high-leverage character as in any AD engagement, but with a bank-specific priority stack. Disabling stale Domain Admin accounts (especially those from acquired institutions), enabling SID filtering on any active domain trust, and removing MSP RMM accounts from Domain Admins all happen on Day 1. These changes do not touch the core banking platform and do not require vendor coordination. They are pure configuration changes that close the highest-risk BloodHound paths immediately. The evidence artifacts - a screenshot of the Domain Admins group before and after, a change ticket, an updated PingCastle trust configuration check - are produced automatically as part of the change window documentation and go directly into the examiner evidence package.
Core banking platform service account remediation is deferred to Day 30 precisely because it requires vendor coordination. In our experience, Fiserv, Jack Henry, and FIS all have documented procedures for migrating application service accounts to gMSA on current platform versions. The process typically requires a support ticket, a maintenance window approved by both the bank and the vendor, and a post-migration validation pass on the core platform's transaction processing. Banks that defer this change indefinitely because "the vendor said it might break something" are leaving their highest-risk finding open indefinitely. A well-scoped engagement includes a vendor coordination milestone at Day 14 (initiate vendor support ticket, document gMSA eligibility per current platform version) and a Day 30 execution window.
Section 8
Delivery Models: MRA Response, Exam Prep, Quarterly Retainer, and M&A Integration
The right delivery model for a bank AD assessment is dictated by the trigger. Banks face four distinct trigger scenarios, each with different timeline pressure and different examiner evidence requirements.
Model 1: MRA response engagement (accelerated)
Triggered by a drafted or final MRA related to privileged access, identity governance, or third-party access management. The bank has a 45 to 90-day window to submit a corrective action plan, and the examiner expects documented evidence of an independent assessment. Timeline: 8 to 12 business days. Deliverable: assessment report, findings register with regulatory mapping, and an attestation letter addressed to the board and the qualified individual. Premium of 20 to 30 percent over standard fixed-fee pricing to reflect the compressed schedule. Out-of-pocket: USD 9,000 to USD 18,000 for Community Bank tier, USD 20,000 to USD 35,000 for Regional Bank tier.
Model 2: Pre-examination prep (standard)
Triggered by an upcoming OCC, FDIC, Federal Reserve, or NCUA IT examination cycle - typically 60 to 120 days before the examination team arrives. The objective is to identify and remediate findings before the examiner sees them, and to prepare a proactive evidence package that demonstrates the board's awareness and management's active oversight. Timeline: 12 to 20 business days for the assessment, followed by a 30 to 60-day remediation window before the examination. Out-of-pocket: standard fixed-fee pricing per tier. Best when the institution has had prior examination findings in the identity governance category and wants to demonstrate documented improvement.
Model 3: Quarterly retainer aligned to examination cadence
For institutions that want a continuous posture trend line rather than a single annual snapshot. Four assessments per year, each producing an updated findings register, a BloodHound path-delta report showing path reduction since the prior quarter, and a refreshed attestation letter for the board and the qualified individual. The qualified individual can include the quarterly attestation letters in the annual GLBA Safeguards Rule report to the board. NCUA and OCC examiners who receive four consecutive quarterly attestation letters showing declining finding counts and declining BloodHound path counts typically treat the identity governance program as demonstrably improving and reduce the examination depth for that control domain. Annual retainer pricing is approximately 50 to 55 percent of the cost of four standalone assessments.
Model 4: Post-M&A integration assessment
Triggered by the completion of a bank or credit union acquisition, typically run 30 to 90 days after the legal close date. The scope focuses specifically on the acquired institution's domain forest, the trust relationship established between the acquired and acquiring forests, the stale service accounts from the acquired entity's core platform, and the SID filtering configuration on the trust. This engagement produces a focused findings register for the M&A-specific risks and a recommendation on trust architecture going forward (consolidate domains versus maintain separate forests with selective trust and SID filtering enabled). Out-of-pocket: USD 8,000 to USD 16,000 for a typical credit union or small-bank acquisition target; regional-bank acquisition targets follow the Multi-Domain pricing.
| Model | Trigger | Timeline | Community Bank pricing |
|---|---|---|---|
| 1. MRA response | Examiner MRA issued | 8-12 business days | USD 9,000 - 18,000 |
| 2. Pre-examination prep | Exam cycle 60-120 days out | 12-20 business days | USD 7,500 - 14,000 |
| 3. Quarterly retainer | Continuous regulatory cadence | Quarterly cadence | USD 24,000 - 32,000/yr |
| 4. Post-M&A integration | Acquisition legal close | 10-16 business days | USD 8,000 - 16,000 |
FAQ
Six Questions We Get on Every Bank AD Assessment Call
Our OCC examiner issued an MRA for privileged access. Will this assessment close it?
An AD assessment with a documented scope, a findings register with regulatory mapping, a remediation plan, and a signed attestation letter is the standard corrective action evidence for an MRA tied to privileged access or identity governance. Examiners expect to see independent third-party validation, not a self-assessment. The attestation letter must be signed by a named qualified individual and addressed to the board. We have delivered this package to banks under MRA from OCC, FDIC, Federal Reserve, and NCUA examiners. In all cases the examiner accepted it as responsive evidence at the next examination contact. The MRA is typically downgraded from open to a monitoring track item, or closed entirely, within one examination cycle if the Critical and High findings are remediated and the evidence package is complete.
Can we rotate the Fiserv or Jack Henry service account passwords without breaking the core platform?
Yes, but it requires vendor coordination and a planned maintenance window. Both Fiserv and Jack Henry have documented procedures for service account password rotation and for migrating service accounts to gMSA on current platform versions (typically DNA 4.x and later for Fiserv, Silverlake 2021 and later for Jack Henry). The process requires a support ticket with the vendor, a test in a non-production environment if one exists, and a maintenance window coordinated with the vendor's support team. Banks that have been deferring this change because they fear a production impact are typically surprised to find that the actual change window is 2 to 4 hours and the vendor's documented process is straightforward. We include vendor coordination milestones explicitly in the remediation plan so this does not remain an indefinitely deferred item.
Our MSP manages our entire IT environment. Can we still limit their Domain Admin access?
Yes, and this is increasingly a contractual expectation under FFIEC third-party risk management guidance. The model we implement is just-in-time (JIT) privileged access: the MSP's domain account has no persistent elevated privileges, and when an elevated-access task is required, the technician requests a time-limited elevation through a PAM tool that the bank controls (Microsoft Entra PIM, CyberArk, BeyondTrust, or a simpler group-based JIT model if a full PAM product is not in scope). The elevation is logged, time-boxed (typically 2 to 4 hours), and automatically revoked. Every MSP that has worked with banks on this model has accepted it once the legal basis (FFIEC third-party guidance, GLBA Safeguards Rule) is cited in the contract amendment discussion. The technical implementation is a half-day project for a competent identity engineer.
We acquired a credit union two years ago. Do we need to address the legacy domain trust now?
Yes. Acquired-institution forest trusts are a consistent examiner finding category because they represent a documented, deferrable, low-priority task that tends to be open for years after the integration period ends. The specific risk - SID filtering off, stale service accounts with elevated permissions in the acquiring forest, bidirectional trust allowing lateral movement from the acquired domain to the production domain - is well-understood and documentable. An examiner who sees a bidirectional trust to an acquired institution's forest with no documented governance around it will raise a finding. The remediation is not necessarily a full domain decommission; the minimum acceptable control is SID filtering enabled, all stale accounts from the acquired domain removed from privileged groups, a documented quarterly review of trust-related accounts, and a decommission timeline in the IT strategic plan. Most of this work fits in a single 2-hour change window.
Does this assessment satisfy the GLBA Safeguards Rule requirement for periodic testing?
An AD security assessment satisfies the Safeguards Rule's Section 314.4(i) requirement for periodic monitoring and testing of the effectiveness of the information security program's key controls, systems, and procedures. It is not the same as a penetration test, and a complete Safeguards Rule compliance program typically requires both - the AD assessment covering identity infrastructure effectiveness, and a penetration test covering perimeter and application-layer controls. For the access control provisions of Section 314.4(f), the AD assessment is the primary evidence vehicle: it documents which access controls are in place, which are absent, and what the remediation plan and timeline are. We include a Safeguards Rule compliance mapping table in every bank deliverable that lists each applicable Section 314.4 subsection and the assessment findings and controls relevant to each.
How much access does the assessor need, and will data collection affect the core banking platform?
Data collection requires a read-only domain account with no special privileges beyond Authenticated Users - the same level of access any domain-joined workstation has by default. BloodHound CE's SharpHound collector performs LDAP reads against the domain controllers and can be tuned to throttle its query rate if the DCs are under load. PingCastle performs a single LDAP pass per domain controller and completes in 10 to 40 minutes. Neither tool touches the core banking platform, its database, or its application services. We schedule collections during off-peak hours (typically between midnight and 6:00 AM on a weekday) and document a change window with named approvers in the engagement plan. In bank engagements we have never had a collection-related disruption to the core platform or to any other production system.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.