What MIRRI Decree 184/2026 Requires for Identity and Access Management

From 1 January 2027, administrators of public-administration information technology (ITVS, informačné technológie verejnej správy) in Slovakia follow a new decree on security measures. Under § 2 of Act 95/2019, an information system is one form of information technology, so ITVS includes public-administration information systems (ISVS, informačné systémy verejnej správy); Annex 2 of the decree uses both abbreviations. Decree No. 184/2026 Coll. of the Ministry of Investments, Regional Development and Informatization (MIRRI) replaces Decree 179/2020 from that date. Its Annex 2 lists 181 minimum security measures, and thirteen of them, items 99 to 111, form the area called identity and access management (správa identít a prístupov).

Three of those items apply to every administrator, from the smallest municipality to a ministry. They require a defined identity and access management system, a list of all users with their identifiers and authorisations, and mechanisms and tools to manage identities and access for every system. The other ten apply to Categories II and III, and they include an annual review of access accounts and permissions with a record that must be kept until the next audit or self-assessment has ended.

Short answer: Decree 184/2026 requires every ITVS administrator to know which systems, identities, technical accounts and administrators it has, to keep a list of users and their authorisations, and to use mechanisms and tools for identity and access management across all its systems. Category II and III administrators must also manage the full identity lifecycle, apply role-based access and least privilege, and review accounts and permissions at least once a year with a retained record. Until 30 June 2027, the new minimum measures count as adopted if you have adopted the measures of your category under Annex 2 of Decree 179/2020.

This guide explains which category applies to whom, what each of items 99 to 111 asks for and what evidence to keep, how the decree differs from the NBÚ decree for operators of essential services, and what changed compared with 179/2020. It is based on the official texts on Slov-Lex checked on 21 October 2026, with item wording and category columns checked in the legally binding PDF. It is practical guidance, not legal advice. Your category, risk analysis and documentation remain your organisation’s decisions.

Key dates

The decree was adopted on 1 July 2026 and published in the Collection of Laws on 9 July 2026. It is issued under § 31(i) of Act No. 95/2019 Coll. on Information Technologies in Public Administration, which makes the administrator (správca) responsible for adopting and carrying out security measures for the public-administration IT in its care (§ 18(1) of the Act).

Section 5(1) deems the whole of Annex 2 adopted, so the transition covers the new items as well, but it ends on 30 June 2027. Both halves of § 5(1) refer to the category that applies under § 1 of the new decree. In our reading, an organisation whose category changes (for example a chamber, Category I under § 3(2)(e) of 179/2020 but Category III under § 1(6)(z) of 184/2026) therefore needs the 179/2020 measures of its new category for the deeming rule to apply. Our recommendation is to have the items that are new for your category working by 30 June 2027. The comparison with 179/2020 later in this guide shows which ones they are.

Which category applies to your organisation

The category follows the type of organisation. Section 1(4) to (6) of the decree assigns it to the public bodies (orgán riadenia) defined in § 5(2) of Act 95/2019. A Category II organisation applies the measures marked for Categories I and II; a Category III organisation applies all three.

The table shortens the lists. Paragraph 6 alone has 27 entries, so check the full wording in § 1 of the decree if your organisation is not named above.

Two details are easy to miss. An organisation set up by a ministry, a region or another body listed in § 5(2)(a) to (d) of Act 95/2019 is in Category I, unless it is a critical entity under Act 367/2024 on critical infrastructure, in which case § 1(6)(y) places it in Category III. And under § 1(3), where minimum measures of different categories that apply to the same ITVS are duplicated or incompatible, the provisions of the higher category prevail.

What the category means for items 99 to 111

In the identity area, the column marking is simple. Items 99, 100 and 101 are marked for Categories I, II and III. Items 102 to 111 are marked only for Categories II and III. A municipality with 4,000 inhabitants therefore has three identity items to meet, while a city district or a self-governing region has thirteen.

Category I is not free of access obligations elsewhere in Annex 2. Item 3 (a designated person responsible for user access), item 10 (least privilege), item 11 (separation of responsibilities) and items 85 and 86 (a list of staff working on ISVS and ITVS and formalised joiner, mover and leaver processes) apply to all three categories. They are covered in the section on related items below.

Deviations need a documented and approved justification

The minimum can be adjusted only through documented risk analysis. Under § 2(3), a minimum measure of your category need not be implemented if it is not relevant to the risk, if the risk can be avoided by stopping or not starting the activity that causes it, or if the risk can be avoided in another way. Section 2(1)(e) requires the justification of any deviation to be part of risk management, and § 2(4) requires the risk analysis result and the proposed measures, including that justification, to be approved in writing by the statutory body or a manager it authorises.

For identity and access, this means an item you decide not to implement needs a written, approved reason. The absence of a suitable tool is not one of the grounds listed in § 2(3).

Decree 184/2026 and Decree 227/2025 compared

From 1 January 2027, two decrees with very similar identity and access items will be in effect in Slovakia, issued by different authorities for different addressees. Our article What NBÚ Decree 227/2025 Requires for Identity and Access Management covers the NBÚ decree in detail.

Most of the identity items correspond almost word for word. Item 102 matches item 76 of 227/2025, items 103 and 104 match items 78 and 79, item 105 matches item 80, and items 106 to 110 match items 81 to 85. Item 111 matches item 86, which 227/2025 limits to operational technology while 184/2026 applies it to all ITVS and ISVS. What 227/2025 does not contain in its identity area are the three all-category items 99, 100 and 101. What 184/2026 does not contain are items 77 and 87 of 227/2025: item 77 (a separate access-control technology for operational technology) is marked only in the OT column for critical operators, and item 87 (identification of unauthorised radio-frequency devices) is marked only for operators of critical essential services, in both the ICT and the OT column.

When both decrees apply

Some administrators are also operators of essential services. Since 30 April 2026, § 17(1)(g) of Act 69/2018, as amended by Article III of Act 67/2026, lists ITVS administrators to which Category II or III minimum measures apply under a special regulation among the persons entered in the register of operators of essential services. Act 95/2019 then says, in § 18(2), that an administrator who is an operator of essential services adopts and carries out ITVS measures under that Act and also within the scope and under the conditions of a special regulation; the footnote to that sentence (note 20) cites § 20(4) of Act 69/2018, which lists what security measures must at least include. Section 1(3) of Act 95/2019 adds that such an administrator’s duties and powers under Act 69/2018 are not affected by it.

Three notes on this. The footnote to § 17(1)(g) still points to § 3(3) and (4) of Decree 179/2020, which is repealed from 1 January 2027; on 21 October 2026 Slov-Lex listed no later version of Act 69/2018, so no published amendment updates that footnote yet. Section 20(3) of Act 69/2018 says that security measures are adopted and carried out in the scope and manner under § 32(1)(b) of that Act, which is the basis of Decree 227/2025, or under a special regulation, if one is issued, and its footnote names Act 95/2019 among the examples. Neither act says expressly how an administrator that is also an operator of essential services documents the two sets of measures together; in our reading that is a question to confirm with the NBÚ and MIRRI, together with your registration status. Because the annual review is worded almost identically in item 80 and item 105, our recommendation is to run one review whose scope and record satisfy both.

Items 99 to 111 mapped to controls and evidence

The table summarises each item, shows its categories, and suggests a control and the evidence to keep. The control and evidence columns are our recommendations; the decree prescribes outcomes and leaves the choice of tools to you. The exact Slovak wording of the key items is quoted in the sections that follow.

The three items every category must meet

Items 99 to 101 are where 184/2026 departs most from both 179/2020 and 227/2025. They are short, but together they ask for an inventory, a register and a tool decision covering every public-administration information system you administer.

Item 99 asks for a defined and checked system

Item 99 reads: „pre všetky ISVS a ITVS v súlade s bezpečnostnými cieľmi organizácie správcu je definovaný, zavedený a kontrolovaný systém riadenia identít a prístupov organizácie správcu, ktorý obsahuje a) zoznam systémov a spôsob riadenia lokálnych identít a centrálne riadených identít používateľov a tretích strán, b) zoznam a jednotlivé typy identít a používateľov, technických účtov a administrátorov naprieč systémami, c) spôsoby identifikácie a autentifikácie používateľov v jednotlivých systémoch“.

In our reading, the word systém here describes the whole arrangement: rules, responsibilities and records, defined, implemented and then checked. Our recommendation is a document that answers three questions for every system:

• Where do its identities come from? Some systems use a central directory, others keep local accounts. Third-party staff such as suppliers’ administrators need to appear too.
• Which kinds of identity exist in it? The decree names users, technical accounts (technické účty) and administrators. Service accounts used by integrations and scheduled jobs belong here.
• How do people identify and authenticate? For example, directory login with multi-factor authentication, a local password, or a certificate.

A practical format is one table per organisation with a row per ISVS or ITVS. Start from the asset register that § 3 of the decree requires in any case, which must be centrally managed, must reflect the current state and must record asset owners. The identity columns then extend a list you have to keep anyway.

Item 100 asks for one list of users and their authorisations

Item 100 reads: „organizácia správcu vedie zoznam všetkých používateľov, ich identifikátorov a autorizácií v rámci správy ISVS a ITVS“.

This is a register, maintained over time, of who has which account and which permissions. Where permissions are scattered across application databases, spreadsheets and ticket histories, producing it means collecting them from each source. Two practical points follow from the wording, in our reading. The list covers all users, so contractors and supplier staff belong in it. And it covers authorisations, not only accounts, so a list of logins without permissions does not meet it.

For Category I organisations with few systems, the register can be a maintained spreadsheet exported from each application. For organisations with dozens of systems, keeping it current by hand becomes the problem. A governance tool connected to those systems can keep the register current for the systems it covers.

Item 101 asks for mechanisms and tools for every system

Item 101 reads: „organizácia správcu určí, zavedie a používa mechanizmy a nástroje na riadenie identít a prístupov pre všetky ISVS a ITVS“.

The item has three verbs: determine, implement and use. Buying a tool and leaving it unused meets at most the first. The item does not name a product category and does not require one central tool for everything. In our reading, a combination is acceptable, for example a central directory for authentication, an identity governance tool for requests, approvals and reviews, and the application’s own controls where no integration exists, as long as you can show which mechanism governs each system.

Write that mapping down. A one-page decision record that lists each ISVS and the mechanism that manages its identities and access is the simplest evidence for item 101, and it reuses the inventory from item 99.

Item 105, the annual review for Categories II and III

Item 105 reads: „v pravidelných intervaloch, najmenej raz ročne je vykonávaná kontrola prístupových účtov a prístupových oprávnení na overenie súladu schválených oprávnení so skutočným stavom vykonávania oprávnení vrátane detekcie a následného zneplatnenia nepoužívaných prístupových účtov; vyhotovuje sa o tom záznam, ktorý sa uchováva najmenej počas obdobia od ukončenia posledného auditu do ukončenia nasledujúceho auditu alebo samohodnotenia“.

The wording is almost identical to item 80 of Decree 227/2025, and our 227/2025 guide walks through scoping, comparison, unused accounts and retention step by step. Three points are specific to the public-administration decree:

• Category I is not marked. A Category I organisation is not required by item 105 to run the review, although its risk analysis may still lead it there.
• The decree does not say which audit it means. Decree 184/2026 does not define audit or self-assessment; item 76 (Categories II and III) only requires defined rules for audit and control activities. For an administrator registered as an operator of essential services, the natural reference is the cyber security audit and self-assessment under § 29 of Act 69/2018; that is our interpretation, not a statement of the decree. Our recommendation is to keep each review record at least until the next cyber security audit has ended, and to confirm the reference with MIRRI if you are not registered as an operator of essential services.
• Unused and invalidated are not defined. Set a measurable threshold per account type in your access policy, treat rarely used but legitimate accounts (emergency administrator accounts, annual jobs) as documented exceptions, and confirm the dependency of a technical account before you disable it.

A useful record contains at least the date and the person responsible (item 3), the scope with documented exclusions, the reviewers, each keep or remove decision with its date, the unused-account threshold and the accounts found, the outcome of every removal in the target system including failed or pending ones, and open items with owners.

Related items in other areas of Annex 2

Several measures that concern identity and access sit outside the identity area. The categories below were checked in the binding PDF.

• Item 3 (all categories): a designated person responsible for managing user access to the network and ITVS, granting and withdrawing access rights, keeping a register of them and keeping operational records of each access.
• Items 10, 11 and 13 (all categories): least privilege, separation of responsibilities (zásada oddeľovania zodpovedností) and need to know. Item 11 words separation of responsibilities as follows: no user may modify or use the administrator’s assets without authorisation or identity verification.
• Items 85 and 86 (all categories): a list of all employees working on the administration of ISVS and ITVS, and formalised processes for assigning, changing and removing positions for users, administrators and third-party staff.
• Item 87 (Categories II and III): rules for assigning people to roles.
• Item 97 (Categories II and III): multi-factor authentication for remote access.
• Item 58 (Categories II and III): for each ISVS project, a person who oversees the supplier’s security obligations, in particular lists of authorised persons and the assignment of remote access.
• Item 73 (all categories): an internal control system with a list of controls, responsible persons, frequency and a register of controls performed. In our reading, the annual review belongs on that list.
• Items 137 to 141: a log collection and monitoring system (137 to 139, all categories), relevant logs kept for at least 12 months with integrity protection (140, Categories II and III) and activity records that identify who performed the activity (141, Categories II and III).

What changed compared with Decree 179/2020

Decree 179/2020 organised its access rules in area D, Riadenie prístupov, as separate lists per category. Decree 184/2026 uses one table with category columns. The wording is new, so the comparison below is by topic, not a one-to-one match.

In our reading of both texts, the main new work for a Category I municipality is items 99 to 101, and for Categories II and III the main changes are the lifecycle and system-account items, the detection and invalidation of unused accounts, the retention of the review record and the longer log retention. Organisations that followed the six-month privileged review of 179/2020 can keep it: § 1(2) of the new decree requires measures at least at the level of the minimum measures, and § 4(1) allows documented measures beyond the minimum.

Where IGA supports these items

Identity governance and administration (IGA) is software that manages who has access to which applications, who approved it and whether it is still needed. In our assessment, for the systems it is connected to, it supports items 100, 101, 103 and 105 most directly and contributes to items 99, 102, 106 and 107. The decree does not name a product category, so an IGA tool is one way to provide the “mechanisms and tools” of item 101, not a legal requirement in itself.

easyIGA is a business-facing IGA layer built on the open source midPoint platform. For the items above, this is what it does today:

• Lifecycle through midPoint: midPoint connects authoritative identity data with configured policies and target systems, so joiners, movers and leavers run through configured integrations (item 103). easyIGA adds readable requests, decisions and reviews.
• Requests and approvals: employees choose access from a readable catalogue, and your organisation defines who can request each permission and who approves it. Captured approval stages stay in order with the recorded decision maker and time, which gives item 105 the approved state to compare against. See access requests.
• Access reviews: the reviewer sees the person and the access under review with last use, granted by and approved by, when the connected systems and captured approval history provide them. Keeping and removing access are both recorded decisions. See access reviews.
• Removals followed to the result: easyIGA distinguishes verified, pending, failed and unknown outcomes, so a removal decided in the review is not counted as done until the connected system confirms it.
• Missing history stays visible: a direct grant with no matching easyIGA request is marked as granted outside easyIGA, with the creation account, channel and time recorded by midPoint. easyIGA does not reconstruct decisions that were never captured.
• Accounts without an owner: comparing accounts in connected systems with identity records helps identify ownership gaps, including for service accounts, which supports the technical-account part of items 99 and 105. The available view depends on the account type, the connected source and the supported workflow, which our team confirms with you. See orphaned accounts and non-human identities.
• Conflicting access: easyIGA shows the result of midPoint’s configured exclusion policies on the approval card. Creating and simulating these rules inside easyIGA is planned, not available today. See separation of duties.
• Evidence: review evidence exports include the available request and approval history, and retention periods and access to these records are agreed for your deployment. See audit evidence.

Deployment is self-hosted by default, on your infrastructure and in your jurisdiction. For organisations without suitable infrastructure, an EU-hosted deployment operated by our team is available on request (deployment options). For how this works across departments, shared services and suppliers, see public-sector access governance.

What IGA does not do for Decree 184/2026

An IGA tool covers part of the identity area. Plan the rest explicitly.

• Authentication. Item 99(c), items 109 and 110 and multi-factor authentication for remote access under item 97 belong to your identity provider, your applications and your user rules. An approval in easyIGA does not prove that multi-factor authentication was used.
• Recording every use of a permission. Item 102 asks for technologies that record the use of access permissions, item 3 asks for operational records of each access, and items 137 to 141 ask for log collection and retention. Application, authentication and network logs provide that. easyIGA shows last use only when a connected system supplies it, and an access record does not show every action performed inside an application.
• Monitoring of untrusted access. Item 111 needs remote-access and network controls with monitoring.
• Privileged sessions. For item 107, IGA can govern who receives a privileged role. Controlling or recording privileged sessions needs separate tools.
• Systems that are not connected. Items 99 to 101 cover all ISVS and ITVS. A connector supports different operations depending on the application and its configuration, and our team confirms the operations you need when designing the integration. A system with no integration still needs its own entry in the inventory and its own way of feeding the register.
• Your decisions. The unused-account threshold, the review scope, the retention period and any deviation under § 2(3) are decisions for your documentation, approved under § 2(4).
• Compliance itself. A product does not establish compliance. The quality of any review also depends on the source data: a wrong manager or a missing end date in HR records will not be fixed by a better review screen.

Checklist for the transition to 30 June 2027

1. Confirm your category under § 1(4) to (6) of the decree, and whether you are registered as an operator of essential services under § 17(1)(g) of Act 69/2018.
2. Compare your current measures under 179/2020 with items 99 to 111 and list what is new for your category.
3. Designate the person responsible for user access under item 3.
4. Build the item 99 inventory from the asset register: for each ISVS and ITVS, the identity source, identity types, technical accounts, administrators, third parties and authentication method.
5. Produce the item 100 register of users, identifiers and authorisations, and decide how it is kept current.
6. Record the item 101 decision: which mechanism or tool manages identities and access for each system.
7. Give every technical and system account an owner and a purpose.
8. For Categories II and III, define roles and the rules for assigning people to them (items 106 and 87).
9. For Categories II and III, define the unused-account threshold per account type and the exception process.
10. For Categories II and III, run the item 105 review at least once a year and follow each removal to a confirmed result.
11. Keep each review record at least until the next audit or self-assessment has ended.
12. Document and get written approval for any deviation under § 2(3) and (4).
13. Assign owners for authentication, logging, remote access and other controls outside IGA.

Frequently asked questions

Does Decree 184/2026 apply to small municipalities?

Yes. A municipality with up to 6,000 inhabitants is in Category I under § 1(4)(a). In the identity area it must meet items 99, 100 and 101, while items 102 to 111 are not part of its minimum.

Is the annual access review mandatory for Category I?

Not under item 105, which is marked only for Categories II and III. A Category I organisation may still decide to review access as a result of its risk analysis, and items 99 and 100 require the inventory and the user list to be defined, controlled and kept.

Are technical and service accounts covered?

Yes. Item 99(b) names technical accounts (technické účty) and administrators, and items 103 and 104 name system accounts (systémové účty). Give each one an owner who can confirm its purpose.

What happens between 1 January and 30 June 2027?

Decree 184/2026 is already effective in that period, but under § 5(1) the minimum measures of your category count as adopted if you have adopted the measures of your category under Annex 2 of Decree 179/2020 in its version effective until 31 December 2026. From 1 July 2027 that deeming rule no longer applies, so the new items must be met.

Does the decree require an IGA or IDM product?

No product is named. Item 101 requires mechanisms and tools for identity and access management for all ISVS and ITVS. An IGA tool is one way to provide them; 179/2020 had asked for central identity management only in Category III.

We are also an operator of essential services. Which decree applies?

Both can apply. Act 95/2019 § 18(2) requires an administrator that is an operator of essential services to adopt and carry out ITVS measures under that Act and also within the scope and under the conditions of the special regulation its footnote cites, § 20(4) of Act 69/2018; the content of security measures under Act 69/2018 is set by NBÚ Decree 227/2025. Confirm the combination with the NBÚ and MIRRI, and consider one annual review designed for item 80 and item 105 together.

Where is the binding text?

Slov-Lex states that its HTML text is informative and the PDF is legally binding. The PDF of Decree 184/2026, including Annex 2 with the category columns, is linked in the sources below.

For the wider picture, see our NIS2 access-control overview.

Sources and verification record

All sources were checked on 21 October 2026. Item wording and category columns were checked against the binding PDF.

• Ministerstvo investícií, regionálneho rozvoja a informatizácie SR: Vyhláška č. 184/2026 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy, adopted 1 July 2026, published 9 July 2026, effective 1 January 2027. Binding PDF with annexes; Annex 2 PDF. Used: §§ 1, 2, 3, 5, 6, 7; Annex 2 items 3, 10, 11, 13, 58, 73, 85, 86, 87, 97, 99 to 111, 137 to 141.
• Národná rada Slovenskej republiky: Zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe, consolidated version effective from 30 April 2026 to 31 December 2026. A further version effective from 1 January 2027 (also from Act 67/2026) changes §§ 3 and 11, not the sections used here. Used: §§ 1, 2, 5, 18, 31.
• Národná rada Slovenskej republiky: Zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti, consolidated version effective from 30 April 2026; no later version was listed on Slov-Lex on 21 October 2026. Used: §§ 17, 20, 29, 32.
• Národná rada Slovenskej republiky: Zákon č. 67/2026 Z. z., adopted 16 April 2026, published 30 April 2026. Used: Article III (new wording of § 17(1)(g) of Act 69/2018) and Article IV.
• Úrad podpredsedu vlády SR pre investície a informatizáciu: Vyhláška č. 179/2020 Z. z., adopted 22 June 2020, effective 30 June 2020 to 31 December 2026. Binding PDF. Used: § 3; Annex 2 areas D and K.
• Národný bezpečnostný úrad: Vyhláška č. 227/2025 Z. z. o bezpečnostných opatreniach, effective 1 September 2025. Annex 1 PDF. Used: § 32(1)(b) reference in the preamble; Annex 1 items 76 to 87 and their columns for the comparison.