The Principle of Least Privilege in Microservices: A Systematic Mapping Study

Abstract

While Microservice Architectures (MSAs) offer enhanced scalability and maintenance, they introduce significant complexity for access control and, specifically, the rigorous enforcement of the Principle of Least Privilege (PoLP). This lack of clear privilege boundaries is a major security vulnerability in microservice-based systems. To address this gap, this study conducts a systematic mapping study to provide a comprehensive guide and taxonomy on implementing PoLP in MSA. We identify and categorize existing mechanisms, best practices, and the technical and non-technical challenges encountered during implementation. The systematic search identified 25 primary studies, revealing a significant contribution from journal venues, particularly Computers & Security. Key findings detail the top technical challenges, including performance overhead, fragile container isolation, and authentication/authorization gaps inherent in service-to-service communication. Proposed mechanisms are categorized into four groups: policy and access control, code and configuration hardening, runtime/kernel-level methods, and general frameworks. Similarly, organizational challenges are grouped by people/culture, tooling/architecture, process/governance, and resource/expertise. This study provides a valuable roadmap and taxonomy for diverse security stakeholders. The identified research gaps—concerning AI integration, DevSecOps adoption, education, and dynamic analysis—underscore the need to shift from the currently predominantly theoretical approaches towards practical, experimental research to advance the real-world application of PoLP.

1. Introduction

The Principle of Least Privilege (PoLP) dictates that every entity (user, process, or service) must be granted only the minimum access rights required to complete its specific job, serving as a core security tenet for modern systems [1]. Granting permissions beyond necessity increases attack surfaces, magnifies risks of privilege escalation, and exacerbates potential damage in case of a compromise (e.g., overly permissive roles or misconfigured access) [2]. Concurrently, microservices architectures (MSAs) have gained widespread adoption, driven by demands for scalability, agility, resilience, and rapid deployment in cloud-native systems [3]. Gartner predicts that over 85% of organizations will be ‘cloud-first’ by 2025, a shift that effectively necessitates microservices to achieve the agility and resilience required for digital strategies (https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences (accessed on 25 January 2026)). In MSA, complex systems are structured as a collection of fine-grained, loosely coupled software artifacts known as microservices. Each microservice implements a small, specific part—often a single function—of the application’s overall business logic [3,4].

While the MSA paradigm brings operational and maintenance benefits, it raises new and complex security challenges. From the literature, unauthorized access and improper enforcement of access control are among the most common threats in MSA [5]. Moreover, enforcing PoLP in microservices is difficult due to different factors [6,7,8]:

• Distributed nature and dynamic environments: Services are frequently created, scaled, or removed; they communicate across network boundaries; identity and access control policies must adapt dynamically.
• Complexity of policy enforcement: Traditional access control models (e.g., mandatory access control, MAC) may not fully capture contextual or fine-grained requirements in microservices, such as attribute-based or capability-based permissions. Additionally, decentralization increases the complexity of enforcement, in which different microservices are owned by different teams, written in different languages, and deployed on different platforms.
• Awareness and best practices gap: Many practitioners lack sufficient awareness of microservice-specific security challenges.

Empirical security studies indicate that PoLP violations in microservices significantly expand the attack surface and are a leading factor in privilege escalation incidents [5]. Unlike monolithic systems, where access control is centralized and static, microservices require distributed, fine-grained, and dynamically adaptive enforcement due to their ephemeral nature, cross-network communication, and frequent scaling events. Given these complexities, understanding the challenges of implementing PoLP in microservices is essential both from a research and a practitioner perspective. There is a need to synthesize what is known, what works, what does not, and what remains underexplored. This work provides the following contributions:

• Performs this systematic mapping study according to the PoLP in microservices and MSA.
• Determines the most common publication venues in this field.
• Identifies the technical and organizational challenges that arise when enforcing PoLP in microservices.
• Describes the collection of security mechanisms and controls required for PoLP implementation.
• Discusses gaps that remain in research and practice.

The remaining sections of this paper are organized as follows: Section 2 briefly discusses the background of the concepts and approaches utilized. Section 3 explains the research methodology. Section 4 presents and discusses the mapping results. Threats to the study’s validity are presented in Section 5. We present our concluding remarks in Section 6.

2. Background

PoLP requires granting subjects (users, processes, or services) only the permissions strictly necessary to accomplish their tasks. This reduces the system’s attack surface, limits the scope of privilege escalation attacks, and confines the potential damage from compromised accounts. While PoLP has long been considered a fundamental security design principle in traditional systems [9], its enforcement in dynamic, distributed environments such as microservices remains a significant challenge.

Today’s distributed and cloud-native systems rely on MSA. It is an approach where a large application is broken down into a collection of smaller, distinct services. Each service can be developed, deployed, and scaled autonomously, communicating through well-defined interfaces like HTTP/REST [3]. A simplified representation of MSA is shown in Figure 1 (adapted from [5]); this modularity makes the whole system more resilient and easier to update. Subsequently, scalability, agility, and maintainability would be improved with this paradigm compared to monolithic systems.

However, its reliance on inter-service communication, distributed trust boundaries, and container orchestration introduces complex security requirements [5]. In fact, access control is central to PoLP enforcement because microservices are composed of smaller, independent components that require only specific, narrow permissions. A mapping study by [5] highlights that access control, authentication, and secure communication are among the most widely studied threats in MSA, yet challenges persist in real-world deployments. Although models like role-based access control (RBAC) remain widely used, they face scalability and granularity limitations in microservices. The role explosion problem—where too many fine-grained roles must be defined and managed—limits RBAC’s applicability [10]. Attribute-Based Access Control (ABAC) provides more expressive, context-aware policies (e.g., based on service identity, time, or request context), making it more suitable for dynamic environments [10]. However, ABAC introduces policy management complexity and performance overhead. Recent approaches, such as policy-based access control (PBAC) and Zero Trust Architecture (ZTA), have been explored to secure service-to-service communication [11]. Service meshes like Istio (https://istio.io/) or Linkerd (https://linkerd.io/), often combined with external policy engines such as Open Policy Agent (OPA) (https://www.openpolicyagent.org/ (accessed on 25 January 2026)), enable more automated enforcement of PoLP at scale. While RBAC and ABAC offer foundational control, they often fall short in microservices due to role explosion, lack of real-time context adaptation, and insufficient granularity for service-to-service interactions. Emerging models like Zero Trust and PBAC attempt to bridge this gap but introduce new complexities in policy management and runtime overhead.

Accordingly, empirical studies suggest that developers and DevOps teams often lack adequate awareness of microservice-specific security pitfalls, leading to common misconfigurations such as overly permissive access, shared credentials, and improper API gateway rules [8]. A recent study analyzing open-source microservices projects found frequent instances of insecure defaults, weak access controls, and improper authentication setups [12].

In summary, the literature highlights a growing tension: While Microservice Architectures are now mainstream in distributed systems, implementing PoLP remains technically complex and organizationally under-prioritized. Existing access control models provide partial solutions but lack full adaptability to the distributed and ephemeral nature of microservices. A systematic mapping is therefore necessary to synthesize known challenges, consolidate best practices, and identify research gaps in PoLP implementation for MSA.

3. Research Approach

A systematic mapping study is recognized as a key method in evidence-based software engineering (EBSE) [13]. These studies are designed to establish a comprehensive overview of a specific research domain by creating a classification framework and organizing the available evidence within that field [14]. Our systematic mapping study presented was conducted based on the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) checklist [15]. It progresses through identification, screening, eligibility, and inclusion. The identification phase retrieved relevant literature from e-libraries on 1 November 2025. During screening, titles, abstracts, and keywords were reviewed to filter initial results. The eligibility phase then assessed the full texts of potentially relevant articles. Ultimately, publications meeting the inclusion criteria were selected to characterize the PoLP elements in MSA. This systematic mapping study was performed by a team of two academic faculty members. Both researchers participated in the phases of the study.

3.1. Research Question Formulation

The study is driven by five core RQs:

• RQ1: What are the most prominent publication venues for research in PoLP in MSA?
• RQ2: What are the primary technical challenges in implementing the PoLP in MSA?
• RQ3: What mechanisms, tools, frameworks, or best practices have been proposed or adopted to enforce PoLP in microservices?
• RQ4: What organizational or operational challenges (e.g., human-centered factors) affect the adoption of PoLP in microservices?
• RQ5: What are the identified research gaps and future directions for enforcing PoLP in microservices?

3.2. Search Strategy

The search strategy was intentionally generic and simple, focusing on key concepts of population (microservices/MSAs) and intervention (Principle of Least Privilege and access control models), as advised by [16]. This led to the final adopted search string:

• (“least privilege” OR “principle of least privilege”)
• AND
• (“microservices” OR “microservice architecture” OR “MSA”)
• AND
• (“access control” OR “authorization” OR “identity management” OR “RBAC” OR “ABAC” OR “privilege management” OR “service-to-service security” OR “zero trust”)

3.3. Source Selection

For retrieving relevant studies, we adopted the use of the following electronic libraries: IEEE Xplorer, ACM Digital Library, SpringerLink, ScienceDirect, Taylor and Francis, Science Open, Scopus, Semantic Scholar, and Web of Science.

3.4. Study Selection

After automatic searching yielded an initial set of papers, a two-stage screening process was implemented. The first stage involved assessing titles and abstracts for relevance, while the second stage required a full-text review to confirm that the papers met the study’s inclusion criteria. Strict inclusion and exclusion criteria limit the number of papers retrieved by online academic libraries. We established the following inclusion criteria for publications between 2015 and November 2025. The year 2015 was selected as a cutoff due to the confluence of key technological and security milestones: the widespread adoption of Docker in 2013, the release of Kubernetes in 2014, and the emergence of notable microservice-related security breaches and academic attention starting in 2015 [5]. The inclusion criteria were as follows:

• Be written in English.
• Be peer-reviewed papers.
• Address the Principle of Least Privilege (PoLP) in microservices as the core topic.
• Offer a proposal (such as a framework, technique, method, control, or tool) for implementing PoLP within Microservice Architectures (MSAs).
• Present a qualitative or quantitative evaluation of PoLP implementation with microservices or MSAs.

We applied the following exclusion criteria to the selected abstracts and titles to ensure relevance and quality:

• We excluded duplicate and inaccessible studies.
• We excluded studies not focused on PoLP in the context of microservices, as this is our primary area of focus.
• We excluded non-peer-reviewed content (e.g., from preprint repositories).
• We excluded theses (MS/PhD), posters, technical reports, tutorials, editorials, and commentary articles.
• We excluded papers presenting reviews or surveys.
• We excluded papers addressing PoLP implementation in distributed platforms and technologies such as clouds without explicit reference to microservices.
• We excluded papers describing general aspects of Microservice Architectures without significant emphasis on the PoLP issue.

Figure 2 illustrates the details of how this systematic mapping study was carried out, highlighting the number of articles included and excluded at each stage. A total of 144 studies were initially identified; after applying inclusion and exclusion criteria, 25 were classified as primary studies.

3.5. Quality Assessment

As advised by [14], quality assessment is essential to ensure that the selected papers contain sufficient information for reliable data extraction. To achieve this, we evaluated the overall strength and included details of the papers using a four-item questionnaire. This questionnaire was adapted from the criteria established in sources [17,18] and tailored to our specific research topic. The adopted assessment criteria and their associated scoring are summarized in

Table 1. Quality assessment criteria.

Question	Answer
Is the study’s purpose clearly established in the introduction?	Yes/No
Is the chosen research method/design suitable for the study’s aims?	Yes/No
Are the results and findings presented unambiguously?	Yes/No
Are the study’s findings interpreted and discussed appropriately?	Yes/No

.

To determine study quality, four equally weighted criteria were employed, each scored 1 (if met) or 0 (if not met). The four individual scores were summed to create a total quality score. For example, a study scoring ‘Yes’ on all four criteria received a score of 4. Only studies achieving a total quality score of at least 2 were deemed acceptable for inclusion in this research. Discrepancies in mechanism or challenge categorization were resolved through discussion and, if needed, consultation with a third independent expert.

3.6. Information Extraction

Table 2. Data extraction form.

Section 1: Paper Information
Title	Title of the study
Author	Author name(s)
Type	Journal, Conference, Workshop, or Symposium
Year	The year of the study
Section 3: Data Extraction
Data Extraction Item	Considered RQ
Category (analysis, proposal, review, case study, etc.)	RQ2
Objective (objectives/aims of the study)	RQ2, RQ5
PoLP mechanisms (security mechanisms, tools, frameworks, or best practices proposed or used)	RQ3
Validation (verification and validation techniques used)	RQ2
Technical challenges (list the technical difficulties in PoLP implementation)	RQ1
Organizational/operational challenges (non-technical factors discussed (e.g., security culture and human-centered factors)	RQ4
Identified gaps/future directions (explicitly stated research gaps or limitations)	RQ5
Data analysis (whether quantitative, qualitative, mixed, or not applicable)	RQ2
Domain/platform (domains or platforms applicable for the proposed solution)	(Contextual)

illustrates the data extraction form used for this study. For each paper, we extracted its metadata (title, author(s), publication type, and year) along with specific information required for our subsequent analysis. These include the list of PoLP mechanisms and frameworks used by the study, and technical and operational/organizational challenges. This structured methodology ensured that all relevant information was captured, thus allowing for an exhaustive review of PoLP in microservices.

4. Results of the Mapping

We now detail and describe the findings of the mapping study, which directly answer the five RQs described in Section 3.1.

4.1. Overview of Selected Studies

In October 2025, a targeted search was performed using a designed query on several selected libraries. The process initially yielded 144 papers; however, after gathering the results, inaccessible and duplicate entries were removed, resulting in a final collection of 118 distinct papers published since 2015. After applying the inclusion and exclusion criteria, 93 studies were excluded for their irrelevance. Only 25 papers were approved.

Table 3. Quantitative distribution of studies after applying the a priori inclusion/exclusion criteria defined in Section 3 (2015–2025).

Library	Discovered Studies	Inaccessible Studies	Repeated Studies	Exclusive Studies	Primary Studies
ACM	26	3	1	13	9 [19,20,21,22,23,24,25,26,27]
IEEE	5	0	0	1	4 [28,29,30,31]
Science Direct	53	0	0	43	10 [32,33,34,35,36,37,38,39,40,41]
Springer	32	18	0	12	2 [42,43]
Taylor and Francis	21	0	1	20	0
Others (Science Open, Scopus, Semantic Scholar, and Web of Science)	7	0	3	4	0
Total	144	21	5	93	25

details the contribution of each library. The table also indicates that IEEE Xplore and ACM contribute the maximum number of publications; conversely, no papers from Taylor and Francis met our inclusion criteria. It is worth noting that the main reason for the high paper exclusion rate (64.5%) was the presence of surveys or reviews, which accounted for 35% of the excluded studies. The second major reason was applying PoLP from a hardware perspective, a common trend in papers published by ACM, whose main focus is on computer architecture or embedded systems, which did not meet the inclusion criteria.

Figure 3 illustrates how the selected studies are distributed by year and source. We can observe an increase in the number of empirical studies that deal with the subject, according to the analysis of the trend in publications that was carried out. The dotted trend line suggests a positive overall trend in the percentage of publications over time. This trend highlights the rising importance of PoLP implementation in MSA during recent years.

Figure 4 presents a distribution of research strategies identified. The data illustrates a clear transition from foundational Analysis and Framework development (2015–2022) toward the recent dominance of Solution Proposals (2023–2025). This shift highlights the maturation of the field, moving from the theoretical identification of over-privilege risks toward the engineering of automated enforcement and dynamic authorization tools.

An assessment of the primary studies’ suitability was conducted using Word Clouds. Figure 5 shows the frequency distribution of terms found in the titles and abstracts. The most dominant terms are security, container, application, microservices, system, network, attack, and policy.

4.2. Analysis of Publication Venues and Source Types (RQ1)

This study analyzed the types of sources and publication venues used in the field of study to answer Research Question 1 (RQ1). The selected studies appeared in four primary types of publications: journal articles, conference proceedings, workshops, and symposiums.

Table 4. Publication venue and quality assessment score for included studies (legend: C = conference, J = journal, W = workshop, S = symposium).

ID	Cite	Year	Type	Publisher	Score
PS (1)	[19]	2024	C	ACM	4
PS (2)	[20]	2023	C	ACM	4
PS (3)	[21]	2019	W	ACM	4
PS (4)	[22]	2017	C	ACM	4
PS (5)	[23]	2023	S	ACM	4
PS (6)	[24]	2017	W	ACM	3
PS (7)	[25]	2022	C	ACM	4
PS (8)	[26]	2023	J	ACM	4
PS (9)	[27]	2020	C	ACM	4
PS (10)	[28]	2025	C	IEEE	4
PS (11)	[29]	2025	J	IEEE	2
PS (12)	[30]	2024	C	IEEE	2
PS (13)	[31]	2024	C	IEEE	4
PS (14)	[32]	2023	J	Science Direct	4
PS (15)	[33]	2023	J	Science Direct	2
PS (16)	[34]	2025	J	Science Direct	4
PS (17)	[35]	2025	J	Science Direct	4
PS (18)	[36]	2025	J	Science Direct	4
PS (19)	[37]	2023	J	Science Direct	3
PS (20)	[38]	2023	J	Science Direct	4
PS (21)	[39]	2024	J	Science Direct	4
PS (22)	[40]	2023	J	Science Direct	4
PS (23)	[41]	2023	J	Science Direct	4
PS (24)	[42]	2020	C	Springer	4

provides a detailed breakdown of these selected studies, including the year they were published, the type of publication, the method used to locate them, and their assigned quality assessment score. Because the exclusion and inclusion criteria have been applied strictly, the final set of studies achieved a high score in the quality assessment.

Fifty-two percent (52%, n = 13) of the studies were published in journals, while those published in conferences were 36% (n = 9). The remaining studies were published in workshops and symposiums, totaling 12% (n = 3). It is worth mentioning most research on MSA security appears in journals because the nature of this work demands significant rigor and space for validation, making journals the ideal publication venue. Nevertheless, as this area expands, we expect to see more specialized conferences, workshops, and symposia emerge to cover the specifics of software architecture and security principles. Table 4 shows that the majority of primary papers were retrieved from the Science Direct library (40%, n = 10), followed closely by those from ACM (36%, n = 9). The Springer library contributed the fewest studies, likely because its scope is multidisciplinary—encompassing medical and life sciences—rather than focused purely on computing, unlike ACM. As previously noted, all papers retrieved from the other databases detailed in Table 3 were excluded because they did not meet our criteria.

Key journals publishing papers on PoLP in MSA are identified in

Table 5. Venues publishing multiple selected studies.

Venue	URL	Freq.
Computers &Security	https://www.sciencedirect.com/journal/computers-and-security (accessed on 25 January 2026).	6
European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE)	https://www.esec-fse.org/index (accessed on 25 January 2026).	2

, which lists venues with a publication frequency of two or more. Computers & Security is the top-ranked journal, having published six primary studies in the domain. This is followed by the European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), which accounts for two papers.

4.3. Analysis Based on Technical Challenges (RQ2)

The adoption of microservices as a modern software engineering paradigm inherently brings forth a new set of security threats and vulnerabilities [2]. Accordingly, enforcement of the PoLP in such environments faces significant technical challenges.

Table 6. Common technical challenges in enforcing the PoLP in the MSA.

#	Technical Challenge	Studies	Freq.	%
1	Performance Overhead	[23,34,37,42,43]	5	20%
2	Fragile/Insufficient Container Isolation	[21,23,33,34]	4	16%
3	Authentication and Authorization Gaps	[19,30,32,40]	4	16%
4	Service-to-Service Communication	[19,32,37]	3	12%
5	Integration with Legacy/Monolithic Systems	[29,36,41]	3	12%
6	Verification Limitations	[24,33,43]	3	12%
7	Configuration and Secrets Management	[19,31,32]	3	12%
8	Traditional/Perimeter-Based Security Insufficiency	[26,30,41]	3	12%
9	General Overhead and Integration Complexity	[20,22,41]	3	12%
10	Poor Visibility/Logging and Monitoring	[20,25,32]	3	12%

outlines the 10 most common technical challenges and difficulties encountered by researchers and practitioners when implementing PoLP in microservices. They are, in order, Performance Overhead, Fragile/Insufficient Container Isolation, Authentication and Authorization Gaps, Service-to-Service Communication, Integration with Legacy/Monolithic Systems, Verification Limitations, Configuration and Secrets Management, Traditional/Perimeter-Based Security Insufficiency, General Overhead and Integration Complexity, and Poor Visibility/Logging and Monitoring. Besides the technical challenge, Table 6 presents two key metrics for each identified challenge: the total number of studies in which the challenge was found, and the corresponding percentage of the primary studies. Due to space constraints, we have discussed the three most significant challenges in detail, those encountered by at least four studies.

4.3.1. Performance Overhead (Five Papers)

This challenge refers to three components introduced by PoLP enforcement mechanisms: computational cost, latency, and resource consumption. In a microservice environment, security checks are performed for every cross-service request, often involving multiple hops and security layers (e.g., service mesh sidecars, mandatory access control checks). These extra steps (like encryption/decryption, context validation, or policy lookups) add up, leading to (a) increased latency [37,42], (b) higher CPU/memory usage [23,34], and (c) the need to simplify or forgo granular PoLP enforcement to maintain service speed [43]. Mitigation examples from primary studies include the use of eBPF for lightweight security auditing [23] and optimized policy caching in service meshes [37].

4.3.2. Fragile/Insufficient Container Isolation

This challenge relates to the limitations of the underlying container technology (like Docker or Kubernetes) in guaranteeing strict resource and process separation needed for PoLP. Container isolation is often based on Linux kernel features like control groups (cgroups) and namespaces. However, vulnerabilities or misconfigurations can allow a compromised container to (a) escalate privileges [23], (b) compromise the host machine [19], and (c) access shared resources or libraries that should be isolated [23], and additionally, (d) the dynamic nature of containers conflicts with traditional static Mandatory Access Control (MAC) systems, which rely on static security labels assigned to subjects (users/processes) and objects (files/resources), making PoLP difficult to enforce effectively [34]. Accordingly, modern container security models have shifted to RBAC, which has become the modern, dominant standard for microservice and cloud environments like Kubernetes [44].

4.3.3. Authentication and Authorization Gaps

This is the core functional challenge of PoLP: accurately identifying and limiting permissions for every service and user in a distributed system. While RBAC is more suitable for microservices and cloud environments than static ones like MAC (Section 4.3.2), it is still inadequate because it lacks the necessary context and granularity [30]. The system requires a robust, dynamic mechanism (often part of a Zero Trust Architecture/ZTA) to ensure a service accessing an API only has the minimum privileges needed for that specific request [19,32,40].

4.4. Mechanisms, Tools, Frameworks, and Best Practices to Implement PoLP in MSA (RQ3)

Mechanisms, tools, and best practices used to enforce PoLP across the 25 papers are grouped into four high-level categories: policy and access control, runtime and kernel level, code and configuration hardening, and general frameworks and practices. We established a publication threshold of two, meaning we consider only those mechanisms appearing in more than two publications. Mechanisms appearing in two or fewer publications are excluded due to an assumption of non-dominance.

• Policy and access control: Techniques focusing on who (identity) and what (action) is permitted.
• Code and configuration hardening: This group focuses on proactive analysis and reduction of the service’s attack surface and reducing its inherent privilege requirements before deployment.
• Runtime and kernel level: Methods concentrating on how services are isolated and restricted at the OS or container runtime level, using low-level technologies to strictly enforce resource limits and prevent unauthorized actions.
• General frameworks and practices: This category contains broader security methodologies, operational tools, and adjacent technologies that support a strong PoLP posture through development lifecycle, monitoring, or specialized applications.

Table 7. Common mechanisms, tools, and frameworks for enforcing PoLP in MSA.

Mechanism Category	Sub-Category	Freq.	%	Studies
Policy and Access Control	Zero Trust	11	44%	[20,26,27,28,29,30,31,36,40,41,42]
	RBAC
	Dynamic Standards International (DSI)
	Service Mesh
	Kubesonde
General Security Frameworks and Practices	K8s Operators	10	40%	[21,25,31,32,36,37,38,39,40,43]
	DevSecOps/SecDevOps
	Secure Software Development
	Distributed Ledger
	Blockchain
	Smart Contracts
Code and Configuration Hardening	Debloating	5	20%	[19,22,24,33,37]
	Threat Modeling
	Static/Program Analysis
Runtime and Kernel Level	Extended Berkeley Packet Filter (eBPF)	3	12%	[23,34,43]
	Seccomp
	Sandboxing

visualizes the classification of tools and mechanisms implemented in the proposed solutions. For each entry, it specifies its proportional rate against the whole set of primary studies. The results show a strong emphasis on policy and access control techniques (44%, n = 11), enforcing general security frameworks and practices (40%, n = 10), code and configuration hardening (20%, n = 5), where less attention is being paid to runtime and kernel level (12%, n = 3). To clarify the relationship between technical challenges and implementation mechanisms, Table 7 maps each primary challenge (from Table 6) to the relevant mechanism categories. For example, Performance Overhead (#1 in Table 6) is commonly addressed through kernel-level methods (e.g., eBPF) and optimized policy engines, while Authentication and Authorization Gaps (#3 in Table 6) are targeted by policy-based approaches such as zero trust architectures and service meshes. This mapping illustrates how the identified mechanisms are designed to mitigate specific technical pain points in PoLP enforcement.

Trade-offs exist across categories: policy-based approaches offer flexibility but incur runtime overhead; kernel-level methods provide strong isolation but require deep expertise; code hardening reduces attack surfaces but can increase development time. The reader is assumed to be familiar with the mechanisms and frameworks listed in the above table such as Dynamic Standards International (DSI), K8s Operators, DevSecOps, and eBPF. Readers seeking further information may consult standard texts on microservice or container security.

4.5. Analysis Based on Organizational Challenges (RQ4)

Enforcement of the PoLP in microservice-based systems does not only face technical challenges (Section 4.3) but also organizational ones. These challenges are grouped into four high-level groups: people and culture, tooling and architecture gaps (ad hoc/legacy), process and governance (compliance), and resource and expertise.

• People and culture: This is the most common group, encompassing human factors, mindset, and inter-team dynamics. It highlights that the most persistent challenges are often non-technical and rooted in human behavior and organizational structure.
• Tooling and architecture gaps (ad hoc/legacy): This group focuses on shortcomings in existing technical mechanisms and the lack of mature, standardized, and automated solutions required for the microservices paradigm.
• Process and governance (compliance): This group centers on the formal requirements, mandates, and structural procedures necessary for policy definition, enforcement, and auditing, which are often complicated by the distributed nature of microservices.
• Resource and expertise: This group addresses the tangible limitations in staff, budget, and time, particularly the ongoing effort required to manage security in a microservices environment.

Table 8. Common non-technical challenges (i.e., organizational and operational) in enforcing the PoLP in MSA.

Organizational Challenge	Sub-Category	Studies	Freq.	%
People and culture [19,21,22,23,26,28,30,32,38,40,41,42,43] (56%, n = 14)	Security Awareness and Training	[19,21,22,30,32,38,42,43]	8	32%
	Cultural and Organizational Barriers	[19,28,32,41]	4	16%
	Speed vs. Security Conflict	[23,26,40]	3	12%
	Cross-Team Coordination/Collaboration Gaps	[19,20,40]	3	12%
Tooling and architecture gaps (ad hoc/legacy) [20,21,22,24,25,27,28,29,30,31,33,34,39] (52%, n = 13)	Manual Configuration Burden/Errors	[25,31]	2	8%
	Inadequate/Legacy Policy Mechanisms	[27,29]	2	8%
	Ad Hoc/Non-Standardized Solutions	[24,25,33,34,39]	5	20%
	Insecure Defaults/Packaging	[20,22]	2	8%
	Third-Party Trust Issues	[21]	1	4%
	Need for Dynamic Control Management	[34]	1	4%
	Industry-Specific Security Needs (EHR)	[30]	1	4%
Process and governance (compliance) [19,20,26,29,30,32,36,43] (32%, n = 8)	Governance and Regulatory Compliance	[19,29,30,32,36,43]	6	24%
	Policy Enforcement Complexity/Visibility	[20,26,32]	3	12%
Resource and expertise [19,28,32,35,37,42,43] (28%, n = 7)	Operational Overhead and Expertise	[28,35,37,42]	4	16%
	Resource Constraints/Cost	[19,32,43]	3	12%

presents the most frequently encountered non-technical/organizational challenges, categorized according to our previous four classifications. The results indicate that the most emphasized challenges are, in descending order, people and culture (56%, n = 14), tooling and architecture gaps (ad hoc/legacy) (52%, n = 13), process and governance (compliance) (32%, n = 8), and resource and expertise (28%, n = 7).

We have discussed the most significant organizational challenges in detail. Here is a summary of each challenge group.

4.5.1. People and Culture

This group represents the most significant hurdle, as securing microservices is often hindered by human factors and organizational mindsets [19,28,32,41]. A pervasive lack of security awareness and training among developers and administrators [19,22,30,32,38,42,43] leads to misunderstandings of security best practices [40]. This is exacerbated by a cultural conflict where the pressure to achieve deployment speed often overrides security risks [28], leading developers to prioritize convenience over security [23] or focus exclusively on application logic rather than the underlying infrastructure security [35]. Furthermore, enforcing PoLP requires better cross-team coordination and collaboration [19,20,40], which is frequently cited as a missing link in the development pipeline. Actionable practices to address cultural barriers include integrating security champions into DevOps teams, implementing gamified security training, and adopting ‘security by design’ workshops to align speed and safety objectives.

4.5.2. Tooling and Architecture Gaps (Ad Hoc/Legacy)

The distributed and dynamic nature of microservices highlights the inadequacy of traditional security tooling. Many current solutions are ad hoc, non-standardized [24,29], or lack generalization across platforms [25,33], complicating the deployment of generic security solutions [33]. Relying on manual configuration is time-consuming, demands specialized knowledge, and increases the risk of human error and misconfiguration [25,31]. Existing inadequate/legacy policy mechanisms, such as static virtual machine security groups [29] and traditional RBAC [27], are over-permissive and cannot enforce the fine-grained least privilege required for complex microservice workflows. Additionally, insecure defaults and the ease of container creation often encourage the packaging of unnecessary components [20,22].

4.5.3. Process and Governance (Compliance)

This group encompasses the formal structural and mandated procedures required to maintain a secure and legal microservice environment. Organizations face pressure from governance and regulatory compliance mandates [19,29,30,32,36,43], with breaches often having severe consequences [30]. The complexity of policy enforcement and visibility is a major challenge [32], as administrators struggle with the lack of visibility into inter-container dependencies necessary to define effective least-privilege communication policies [26]. Furthermore, organizational gaps in policy enforcement [19] often mean that even when policies are defined, they are not consistently applied across the dynamic environment.

4.5.4. Resource and Expertise

This challenge group focuses on the practical constraints related to budget, staffing, and specialized knowledge. PoLP enforcement often results in significant operational overhead and expertise gaps [28,37], with new tools like service meshes adding workload for administrators [42]. Many organizations struggle with limited technical expertise and training [30] to manage complex security configurations, and the ongoing security management is often too costly. Therefore, resource and cost constraints [19,32,43] are cited as a direct barrier to investing in the necessary tools and personnel to properly implement and maintain PoLP.

4.6. Analysis of Current Gaps and Future Directions (RQ5)

Building upon the findings presented in the previous sections, this part addresses RQ5 by identifying current gaps in the literature and proposing clear directions for future research. The analysis of the mapping results identified these research gaps.

Table 9. Knowledge gaps and open points for further research.

Research Gap/Research Direction	Sub-Category	Studies	Freq.	%
Automation and AI [19,21,26,28,29,31,38,39] (32%, n = 8)	Overcome manual review difficulty	[19,21,31,39]	4	16%
	Less attention paid to auto-discover dependencies and detect policy misconfigurations	[26]	1	4%
	AI-assisted secret management	[28]	1	4%
Integration into DevOps/DevSecOps [22,28,30,34,35,39] (24%, n = 6)	Integrating security models and tools like Cordon into existing DevOps workflows	[22,34,35,39]	4	16%
	Adopting DevSecOps Practices	[28,30]	2	8%
Education and Training [32,38,39,40,41,43] (24%, n = 6)	Knowledge/Expertise Gaps	[32,41]	2	8%
	Training developers in policy design, risk-based security thinking, and generally encourage collaboration and education	[40,43]	2	8%
	Limited Security Awareness	[39]	1	4%
Dynamic Analysis [22,24,25,28,33] (20%, n = 5)	Overcoming limitations of dynamic analysis, including those used in debloating methods	[24,33]	2	8%
	Tackles the Key Challenge of Runtime Enforcement in Large-Scale	[25]	1	4%
	Combining Static and Dynamic Analysis	[22]	1	4%
	Dynamic analysis to reduce exposure risk	[28]	1	4%

provides a detailed breakdown of the identified research gaps and future directions, listing each point alon gside its primary source, frequency, and percentage of recurrence in the reviewed literature.

These points are elaborated upon in detail below.

4.6.1. Automation and AI

The future direction for enforcing PoLP in microservices is heavily reliant on automation and AI. A critical and pervasive need is for increased automation and automated analysis to enhance cluster security, reduce human error, and overcome the current difficulty of manual security review [19,21,31,39]. This automation should extend to core architectural functions, addressing the lack of automated security-aware composition of microservices [38]. Specifically, there is a gap concerning auto-discovery of dependencies and the detection of policy misconfigurations [26]. Furthermore, leveraging advanced technology, future research calls for dynamic, automated, and AI-assisted secret management to mitigate exposure risks [28] and for the integration of AI/ML-driven analytics to enhance security monitoring and anomaly detection [29].

4.6.2. DevOps/DevSecOps

Integrating security tightly into the development lifecycle through DevOps/DevSecOps is essential for microservice security. A significant gap is the need for the seamless integration of security models and tools into existing workflows [22,34,35,39], which includes overcoming limitations of current solutions that require burdensome infrastructure modifications. Architecturally, adopting the Zero Trust (ZT) principle—‘never trust, always verify’—is a key future direction to strengthen and future-proof microservice security, which is inherently linked to improved DevSecOps practices [28,30].

4.6.3. Education and Training

The human factor represents a foundational gap in securing microservices. There are significant knowledge and expertise gaps [32,41] that must be bridged to improve the theoretical understanding and successful deployment of secure microservice architectures. Concurrently, there is an urgent need for concerted efforts to train developers and staff in policy design, risk-based security thinking, and to encourage general collaboration and education [40,43]. These educational efforts are essential to combat limited security awareness among personnel, which currently hinders effective security implementation [39]. A final word here is our timely recommendation: the MSA concept should be incorporated into foundational software engineering textbooks (e.g., Pressman and Maxim [45]). While MSA has seen widespread adoption across the software industry, this vital architectural style is noticeably absent from these works. A potential explanation for this curricular lag is the typical delay that occurs between the time a new industry pattern, like MSA, achieves popularity and its subsequent formal addition to academic textbooks and course materials.

4.6.4. Dynamic Analysis

Dynamic analysis of microservices remains a crucial area for future development, despite its current limitations. Research must address the key challenge of runtime enforcement in large-scale, highly dynamic environments where security policies are difficult to enforce consistently [25]. This requires overcoming existing limitations of dynamic analysis, particularly when applied to security functions like debloating methods [24,33]. A promising future direction is the formal combination of static and dynamic analysis to create a more robust approach that improves both detection and analysis capabilities throughout the microservice lifecycle [22].

5. Limitations

The extraction process may have resulted in some inaccuracies or bias. Although the chosen databases cover the relevant publications in the domain of applying PoLP in MSA, some other studies have been not included because they are published in non-English languages, or published in open-access preprint repositories such as arXiv and PsyArXiv. Future research should expand its scope by integrating non-English literature, preprint sources, and relevant industry websites.

Word cloud-based assessment shown in Figure 5 suggests that concepts like PoLP were not central to the titles and abstracts of the included literature. This raises a construct validity consideration: PoLP is often embedded within broader security frameworks such as zero trust, service mesh policies, or access control models rather than treated as an explicit keyword or a standalone concept.

Moreover, all materials and templates used in this systematic mapping study are available upon request to researchers interested in replication. However, it should be noted that the dynamic nature of digital libraries may prevent perfect repeatability of the original searches.

6. Conclusions

In this study, we performed a systematic mapping on the implementation and enforcement of the principle of least privilege (PoLP) in microservices, focusing on publication venues, mechanisms/frameworks/best practices, technical and non-technical challenges, and research gaps. The study examined 25 papers published over the past decade. This study provides two novel taxonomies as core contributions: a four-category framework for PoLP enforcement mechanisms (policy/access control, code hardening, runtime/kernel methods, general frameworks) and a four-dimension model for organizational challenges (people/culture, tooling/architecture, process/governance, resource/expertise). These frameworks offer structured guidance for researchers and practitioners in assessing, implementing, and evolving PoLP strategies in microservice environments. Key findings include the following: (1) Journals were the dominant publication venue for this research field compared to other outlets (e.g., conferences and workshops), and the Computers and Security journal published the highest volume of work. (2) The top-three technical challenges to enforce PoLP in microservices and MSA were performance overhead, fragile/insufficient container isolation, and authentication and authorization gaps; RBAC is still inadequate because it lacks the necessary context and granularity. (3) The proposed mechanisms are grouped into four primary categories: policy and access control, code and configuration hardening, runtime and kernel-level methods, and general frameworks and practices. Each of these categories includes sub-elements that are further detailed in Section 4.4. (4) The organizational and operations challenges are similarly grouped into four primary categories: people and culture, tooling and architecture gaps (ad hoc/legacy), process and governance (compliance), and resource and expertise. Details on its sub-elements are provided in Section 4.5. (5) The current research gaps that require further investigation are also divided into four primary categories: automation and AI, DevOps/DevSecOps, education and training, and dynamic analysis. Sub-elements for this group are detailed in Section 4.6.

The findings of this study assist software security researchers and practitioners in better understanding the current state and applicability of PoLP in microservices. Additionally, the work provides a basis for researchers and practitioners to address knowledge gaps. The article concludes by outlining its limitations and identifying key directions for future research in this evolving field. Future work should prioritize the research gaps identified in Section 4.6, particularly the integration of AI/ML for automated policy generation and dynamic privilege adjustment. Recent advances in Proximal Policy Optimization (PPO) for adaptive access control [46] and trusted communication in microservices align closely with our taxonomy of technical challenges and mechanisms, offering promising pathways for next-generation PoLP enforcement in MSA.