Brazil Central Bank Cybersecurity Resolution Guide: CMN 4,893 and BCB 85

Brazil's financial regulators tightened their cybersecurity rules in December 2025, adding mandatory technical controls, annual independent intrusion tests and Pix specific protections to resolutions that every bank, payment institution and broker must already follow. CMN Resolution 4,893 (for institutions authorised by the Banco Central do Brasil) and BCB Resolution 85 (for payment institutions and, after later amendments, brokers, distributors, foreign exchange brokers and virtual asset service providers) set the rules for a cybersecurity policy, an incident response plan, an annual report and the contracting of cloud and data processing services. This guide explains scope, the obligations after CMN 5,274 and BCB 538 of 18 December 2025, the timeline, sanctions, and what the new private key and credential rules mean for machine identities. It is for CISOs, risk and compliance teams at Brazilian regulated institutions and their technology providers. Status checked on 27 October 2026 against the BCB normative database and the Planalto legislation site.

Key takeaways

• Two parallel resolutions. CMN 4,893 covers institutions authorised by the BCB other than those excluded in Article 1; BCB 85 covers payment institutions and, since amendments in 2024 and 2026, brokers, distributors, FX brokers and virtual asset service providers.
• Controls are now listed. The December 2025 amendments set 14 minimum control areas, from authentication and cryptography to cyber intelligence monitoring of the dark web.
• Pix and STR get special treatment. Article 3-A requires MFA for administrative access, isolated environments (a dedicated instance in cloud), credential and certificate monitoring, and bars service providers from accessing message signing private keys.
• Cloud contracts are notifiable. Relevant cloud and data processing contracts must be reported to the BCB within ten days, and foreign provision without an information exchange agreement needs BCB authorisation at least 60 days in advance.
• Sanctions are substantial. Under Law 13,506/2017 the BCB can impose fines up to the greater of 0.5% of financial services revenue or R$2 billion, and can disqualify administrators or revoke authorisation.

Scope: who and what is covered

The two texts are drafted in parallel, so the obligations below apply to both unless stated. They cover the institution's own cybersecurity policy and the contracting of relevant data processing, data storage and cloud computing services, whether in Brazil or abroad. For data protection duties under Brazil's privacy law, see the Brazil LGPD Guide.

Key obligations

Policy, plan, director and report

• Cybersecurity policy (Articles 2 and 3): proportional to size, risk profile, business model, operational complexity and data sensitivity. Conglomerates and cooperative systems may adopt a single policy, recorded at a board or executive meeting. Minimum content includes objectives, controls including traceability, incident registration and cause and impact analysis, scenario guidelines for business continuity, third-party incident handling, data classification, severity criteria, awareness, customer guidance and information sharing with other institutions.
• Disclosure (Articles 4 and 5): share the policy with staff and service providers in clear language, and publish a public summary.
• Incident response plan (Article 6): organisational adjustments, prevention and response procedures, and the area responsible for recording incidents.
• Responsible director (Article 7): one director accountable for the policy and plan, who may hold other roles if there is no conflict of interest.
• Annual report (Article 8): reference date 31 December, presented to the risk committee where one exists and to the board (or executive board) by 31 March. Since the 2025 amendments it must cover relevant incidents in the period, business continuity test results including incident driven unavailability scenarios, and intrusion and vulnerability test results with remediation plans.
• Approval and review (Articles 9 and 10): board approval, documented, reviewed at least annually.

The 14 minimum control areas (Article 3, paragraph 2, from December 2025)

Paragraph 3 applies these controls to secure development and the adoption of new technologies, and paragraph 6 extends them to systems acquired or developed by service providers using the institution's resources.

Pix, STR and market systems (Article 3-A)

• MFA for administrative access to the Pix and STR environments.
• Physical and logical isolation of the Pix and STR environments, with a dedicated instance where cloud services are used.
• Monitoring of credentials and digital certificates, with storage controls, especially for the SPI.
• End-to-end validation of transaction integrity before messages are digitally signed.
• Service provider companies are prohibited from accessing private keys used to sign messages.
• Fraud prevention, detection and response controls when participating in authorised financial market systems.

Compliance must also follow the RSFN technical requirements in the BCB's service catalogue, network manual and SFN security manual. Article 22-B treats the RSFN data communication service as a relevant service for cloud contracting rules, however the institution connects.

Intrusion testing (Article 22-A)

At least annually, performed independently and impartially by a specialised person or company (internal teams may still test), with documented results, vulnerabilities and remediation plans. See the CIS Control 18 Penetration Testing Guide.

Cloud and data processing contracting (Articles 11 to 17)

Timeline and current status

The BCB 538 compliance date was not visible in the text checked; confirm it in the BCB normative database. Article 24 of CMN 4,893 gives the BCB a mandate to issue further rules, including maximum times to resume interrupted relevant services and security requirements for system integration, so expect more detail.

Enforcement and penalties

The BCB supervises compliance and sanctions breaches through its administrative sanctioning regime in Law 13,506/2017. Article 5 lists the penalties, which can be applied singly or together:

• Public admonition.
• Fine, capped by Article 7 at the greater of 0.5% of revenue from financial services and products in the year before the infraction, or R$2 billion.
• Prohibition from providing certain services to supervised institutions.
• Prohibition from carrying out certain activities or types of operation.
• Disqualification from acting as an administrator or member of governing bodies.
• Revocation of authorisation to operate.

Separately, Article 16 gives the BCB a direct lever over cloud provision abroad: without an information exchange agreement, a contract needs its authorisation first.

What it means for AI agents and non-human identities

The December 2025 amendments are some of the most explicit machine identity rules in any financial regulation.

• Signing keys are protected assets: Article 3-A bars service providers from accessing private keys used to sign Pix and STR messages. Keep signing keys in HSMs or key services under the institution's sole control and log every use. See the HSM Deployment and Operations Guide.
• Credentials and certificates are monitored: monitoring of credentials and certificates, and certificate revocation checks under paragraph 12, need an inventory of every machine credential that can act in payment environments.
• Interfaces between systems: control area XIII covers system integration through electronic interfaces. API keys, OAuth clients and mTLS between core banking, Pix gateways and fintech partners fall here. The API Key Management Guide covers rotation and scoping.
• Privileged and VPN access monitoring: automation and agent accounts with administrative rights are privileged access and must be monitored like human admins.
• Integrity before signing: if an AI agent or automated workflow prepares payment messages, the end-to-end integrity check must happen before signing, so an agent cannot alter a transaction after approval.
• Third-party staff and tools: periodic access reviews include third-party staff; include supplier service accounts and integration tokens in the same review.

Compliance steps

1. Confirm which resolution applies. Check Article 1 of CMN 4,893 and the scope of BCB 85 as amended, entity by entity in a group.
2. Gap assess against the 14 control areas and paragraphs 7 to 12, recording evidence for each.
3. Isolate Pix and STR. Confirm physical and logical isolation, a dedicated cloud instance where relevant, and MFA for administrative access.
4. Take control of signing keys. Remove any provider access to message signing keys and document key custody.
5. Commission the annual independent intrusion test and track remediation into the annual report.
6. Refresh the cloud register. List relevant services, confirm the ten-day notices to the BCB were made, and check foreign arrangements under Article 16.
7. Update the annual report template to include relevant incidents, continuity test results and testing results with remediation plans.
8. Stand up cyber intelligence monitoring of the dark web and private groups for leaked credentials and data.

Decision guidance

Detection and measurement

• Monitor: privileged and VPN access attempts, connections at night and on non-business days, signing key use, certificate status, unauthorised devices on the network and dark web mentions of the institution.
• Metric: percentage of the 14 control areas with documented evidence.
• Metric: number of non-institution identities with any access to signing keys (target zero).
• Metric: percentage of intrusion test findings remediated by plan date.
• Metric: days from contracting a relevant cloud service to BCB notice (target ten or fewer).
• Metric: percentage of machine credentials in payment environments with owner, rotation date and monitoring.

Common failure patterns

• Provider-held keys: a payment service provider managing signing keys on the institution's behalf, now expressly prohibited for message signing keys.
• Shared Pix environments: Pix workloads sharing a cloud tenant or network segment with general systems.
• Missed contract notices: the ten-day BCB notice forgotten when a SaaS or cloud contract changes.
• Human-only access reviews: third-party staff reviewed but integration tokens and service accounts ignored.
• Annual report as formality: a report without incidents, test results and remediation plans no longer meets Article 8.

Framework mapping

Practitioner checklist

• Record which resolution applies to each group entity.
• Evidence each of the 14 control areas and paragraphs 7 to 12.
• Confirm Pix and STR isolation and administrative MFA.
• Confirm no provider can access message signing private keys.
• Schedule the annual independent intrusion test.
• Reconcile the cloud contract register with BCB notices.
• Check foreign cloud arrangements against Article 16.
• Present the annual report to the board by 31 March.
• Review machine credentials and third-party access in each access review.

Standards and references

• Banco Central do Brasil: Resolução CMN nº 4.893
• Banco Central do Brasil: Resolução CMN nº 5.274
• Banco Central do Brasil: Resolução BCB nº 85
• Presidência da República: Lei nº 13.506/2017

Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · Brazil LGPD Guide · Financial Services Identity Security Guide · AI Agents in Financial Services Security Guide. This guide summarises CMN Resolution 4,893 and BCB Resolution 85 as amended and checked on 27 October 2026 and is not legal advice.