Aug. 5, 2026
Entra Workload Identities - Simply Explained
Modern cloud environments are no longer accessed only by people. Applications, automation workflows, Azure services, DevOps pipelines, AI agents, and background jobs all require secure access to business resources without relying on human interaction. In this Microsoft Knowledge Nuggets episode, Mirko Peters explains Microsoft Entra Workload Identities in plain English, showing how software securely authenticates to Microsoft 365, Azure, Microsoft Graph, and enterprise services without storing usernames and passwords inside code. Whether you're an Azure administrator, cloud architect, developer, DevOps engineer, or Microsoft consultant, this episode provides a practical foundation for understanding secure application authentication.
UNDERSTANDING USER IDENTITIES VS WORKLOAD IDENTITIES
Microsoft Entra ID manages both human users and software identities, but they operate very differently. Human identities authenticate using passwords, passkeys, Windows Hello, and multi-factor authentication, while applications require non-interactive authentication methods that operate continuously without user involvement. Workload identities provide applications with their own unique digital identity, allowing Microsoft Entra ID to authenticate software independently from human accounts. This separation improves security, eliminates shared service accounts, increases auditing capabilities, and allows every application, automation, or AI workload to receive only the permissions required for its specific business purpose.
APP REGISTRATIONS, SERVICE PRINCIPALS, AND MANAGED IDENTITIES EXPLAINED
Three Microsoft Entra concepts frequently confuse administrators: Application Registrations, Service Principals, and Managed Identities. This episode clearly explains the relationship between these components. Application Registrations define the global identity of an application and describe the permissions it may request. Service Principals represent the application's local identity within an individual Microsoft Entra tenant, where administrators grant permissions and enforce security controls. Managed Identities extend this model by allowing Azure resources such as Azure Functions, Logic Apps, Virtual Machines, and App Services to authenticate automatically without developers managing secrets, passwords, or certificates. Together, these identity models create the secure authentication foundation for modern cloud-native applications.
HOW MANAGED IDENTITIES ELIMINATE PASSWORDS
One of the most significant security improvements in Microsoft Azure is the ability to authenticate workloads without embedding credentials inside applications. Instead of storing passwords, client secrets, or connection strings within source code, Azure resources using Managed Identities request short-lived access tokens directly from Microsoft Entra ID. The episode explains how authentication and authorization work together, how Azure Key Vault integrates with Managed Identities, and why temporary access tokens dramatically reduce the risks associated with credential theft, secret leakage, source code exposure, and long-lived authentication credentials.
SECURING WORKLOAD IDENTITIES IN MICROSOFT AZURE
Workload identities require governance just like privileged user accounts. The discussion explores the importance of least privilege access, Conditional Access for workload identities, workload identity federation, certificate-based authentication, Microsoft Entra ID Protection, logging, monitoring, lifecycle management, and ownership. Mirko explains why every workload identity should have a clearly assigned owner, minimal permissions, continuous monitoring, and regular security reviews. Organizations that neglect application identities often leave behind unused service principals, forgotten secrets, excessive permissions, and automation that continues operating long after the original project has ended.
CHOOSING THE RIGHT IDENTITY STRATEGY FOR EVERY WORKLOAD
Selecting the correct authentication model depends largely on where the application executes. Azure-hosted services should generally use System-Assigned or User-Assigned Managed Identities whenever possible. Applications running outside Azure, including GitHub Actions and external cloud platforms, benefit from Workload Identity Federation instead of long-lived client secrets. Custom enterprise applications often require Application Registrations and Service Principals, while certificates provide a more secure alternative to client secrets when Managed Identities are unavailable. By combining Microsoft Entra Workload Identities, Azure Key Vault, Microsoft Graph, Zero Trust principles, and least privilege access, organizations can significantly strengthen application security while simplifying authentication across Microsoft 365 and Azure environments.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:02,280
You already know how your own work account works.
2
00:00:02,280 --> 00:00:04,440
You sign in with a password or maybe Windows Hello,
3
00:00:04,440 --> 00:00:06,640
approve an MFA prompt and if you forget your password,
4
00:00:06,640 --> 00:00:07,480
you reset it.
5
00:00:07,480 --> 00:00:09,960
But software needs access too and nobody sits at a keyboard
6
00:00:09,960 --> 00:00:11,800
to approve a prompt for a running app.
7
00:00:11,800 --> 00:00:13,600
So a logic app might need to read a mailbox
8
00:00:13,600 --> 00:00:16,520
at two in the morning or an app might need to reach a database
9
00:00:16,520 --> 00:00:18,520
or a backup job might need to save files
10
00:00:18,520 --> 00:00:19,520
while everyone is asleep.
11
00:00:19,520 --> 00:00:20,360
So who is signing in?
12
00:00:20,360 --> 00:00:23,520
And that brings us to Microsoft Entra Workload Identities.
13
00:00:23,520 --> 00:00:24,600
By the end of this episode,
14
00:00:24,600 --> 00:00:27,640
you'll have a plain English map of user identities,
15
00:00:27,640 --> 00:00:31,000
workload identities, app registrations, service principles,
16
00:00:31,000 --> 00:00:32,400
and managed identities.
17
00:00:32,400 --> 00:00:34,600
This matters because old apps often hide passwords
18
00:00:34,600 --> 00:00:36,840
in code, config files, or build pipelines.
19
00:00:36,840 --> 00:00:39,720
Some have broad access, some have no clear owner at all.
20
00:00:39,720 --> 00:00:40,920
And the safer choice often means
21
00:00:40,920 --> 00:00:43,360
the developer never handles a password in the first place.
22
00:00:43,360 --> 00:00:45,880
Let's start with the identity you already use every day
23
00:00:45,880 --> 00:00:48,240
then compare it with the one that software uses.
24
00:00:48,240 --> 00:00:50,480
User identities and workload identities.
25
00:00:50,480 --> 00:00:52,480
People and software both need access
26
00:00:52,480 --> 00:00:54,800
but they prove who they are in very different ways.
27
00:00:54,800 --> 00:00:56,800
Your user identity is your digital badge.
28
00:00:56,800 --> 00:00:58,800
It connects to your name, your work account,
29
00:00:58,800 --> 00:01:00,480
your groups, and the job you do.
30
00:01:00,480 --> 00:01:02,440
When you sign into Outlook Teams, SharePoint,
31
00:01:02,440 --> 00:01:05,320
or another Work app, Microsoft Entra checks that badge.
32
00:01:05,320 --> 00:01:06,920
You might use a password, your phone,
33
00:01:06,920 --> 00:01:08,680
a security key, or Windows Hello.
34
00:01:08,680 --> 00:01:10,160
Then MFA adds another check.
35
00:01:10,160 --> 00:01:12,640
Entra asks, "Is this really Mirko or someone pretending
36
00:01:12,640 --> 00:01:13,560
to be Mirko?"
37
00:01:13,560 --> 00:01:15,480
That works because there is a person at the other end
38
00:01:15,480 --> 00:01:17,840
who can type a code, tap approve, or use a fingerprint,
39
00:01:17,840 --> 00:01:18,640
or face.
40
00:01:18,640 --> 00:01:20,200
A workload identity is different.
41
00:01:20,200 --> 00:01:22,040
It's a digital badge for software.
42
00:01:22,040 --> 00:01:23,760
That software could be an app your team built
43
00:01:23,760 --> 00:01:25,400
an automation that runs on a schedule,
44
00:01:25,400 --> 00:01:27,680
a background service, or even an AI agent
45
00:01:27,680 --> 00:01:30,400
that needs access to company data for a defined job.
46
00:01:30,400 --> 00:01:30,920
Here's the thing.
47
00:01:30,920 --> 00:01:33,480
Think of Microsoft Entra ID as the reception desk
48
00:01:33,480 --> 00:01:35,080
in a modern office building.
49
00:01:35,080 --> 00:01:37,360
When you enter the building, you show your personal badge
50
00:01:37,360 --> 00:01:40,520
so reception can see who you are, which teams you belong to,
51
00:01:40,520 --> 00:01:42,640
and which rooms you may enter.
52
00:01:42,640 --> 00:01:44,960
A workload enters with a badge assigned to its job,
53
00:01:44,960 --> 00:01:46,840
not to a person.
54
00:01:46,840 --> 00:01:49,120
The logic app badge might say, "I send an alert
55
00:01:49,120 --> 00:01:50,880
when a support request arrives."
56
00:01:50,880 --> 00:01:52,440
A virtual machine badge might say,
57
00:01:52,440 --> 00:01:54,960
"I can read one secret from the company vault."
58
00:01:54,960 --> 00:01:56,400
A backup service badge might say,
59
00:01:56,400 --> 00:01:58,440
"I can write backup files to this location."
60
00:01:58,440 --> 00:02:00,280
And a GitHub pipeline badge might say,
61
00:02:00,280 --> 00:02:02,120
"I can deploy this approved piece of code
62
00:02:02,120 --> 00:02:04,080
into this Azure resource group."
63
00:02:04,080 --> 00:02:06,480
Each workload needs access for a reason.
64
00:02:06,480 --> 00:02:08,040
Giving each one its own identity,
65
00:02:08,040 --> 00:02:10,520
let's enter check that reason, recorded silence,
66
00:02:10,520 --> 00:02:11,960
and control what it can reach.
67
00:02:11,960 --> 00:02:13,440
You've probably seen the older approach,
68
00:02:13,440 --> 00:02:15,120
someone creates a normal user account
69
00:02:15,120 --> 00:02:16,880
like service account at company.
70
00:02:16,880 --> 00:02:18,960
Come gives it a password, maybe a mailbox,
71
00:02:18,960 --> 00:02:21,240
maybe brought permissions, and then several apps share it.
72
00:02:21,240 --> 00:02:23,840
That creates a mess, which app used the account last night
73
00:02:23,840 --> 00:02:26,400
who owns the password, what breaks if you disable it?
74
00:02:26,400 --> 00:02:27,920
And if someone copies that password,
75
00:02:27,920 --> 00:02:29,840
can they act as every app that shares it?
76
00:02:29,840 --> 00:02:31,560
A workload identity fixes that model.
77
00:02:31,560 --> 00:02:32,960
It doesn't pretend to be a person,
78
00:02:32,960 --> 00:02:35,800
it gets its own permissions and its own sign-in records.
79
00:02:35,800 --> 00:02:37,760
That separation gives you a much clearer answer
80
00:02:37,760 --> 00:02:38,880
when something goes wrong.
81
00:02:38,880 --> 00:02:41,240
Now, there is one limit you need to keep in mind.
82
00:02:41,240 --> 00:02:43,560
A workload identity can't complete an MFA prompt
83
00:02:43,560 --> 00:02:45,720
because an app can't pull out a phone and tap approve.
84
00:02:45,720 --> 00:02:47,000
So you protect it in other ways,
85
00:02:47,000 --> 00:02:48,840
like controlling what it can access,
86
00:02:48,840 --> 00:02:51,560
how it proves its identity, and where its silence come from.
87
00:02:51,560 --> 00:02:52,640
People use personal badges
88
00:02:52,640 --> 00:02:54,880
because people work in many places and make choices.
89
00:02:54,880 --> 00:02:56,360
Software uses job badges
90
00:02:56,360 --> 00:02:58,960
because software should perform a narrow task repeatedly
91
00:02:58,960 --> 00:03:00,720
without borrowing a human account.
92
00:03:00,720 --> 00:03:02,520
Once you give software its own badge though,
93
00:03:02,520 --> 00:03:03,880
Enter starts using several names
94
00:03:03,880 --> 00:03:05,560
that sound almost identical.
95
00:03:05,560 --> 00:03:08,240
And that's where most beginners get stuck.
96
00:03:08,240 --> 00:03:10,360
The three names that confuse everyone.
97
00:03:10,360 --> 00:03:12,760
You'll see three names in Enter over and over.
98
00:03:12,760 --> 00:03:15,400
Application registration, service principle,
99
00:03:15,400 --> 00:03:16,800
and managed identity.
100
00:03:16,800 --> 00:03:18,680
They all connect, but they're not the same thing.
101
00:03:18,680 --> 00:03:20,480
Let's start with application registration.
102
00:03:20,480 --> 00:03:22,000
Think of an application registration
103
00:03:22,000 --> 00:03:23,880
as the master record for an app.
104
00:03:23,880 --> 00:03:25,400
It's like the design sheet created
105
00:03:25,400 --> 00:03:27,280
before the app ever enters a company.
106
00:03:27,280 --> 00:03:28,640
It describes the app's name,
107
00:03:28,640 --> 00:03:30,320
where it sends people after sign in,
108
00:03:30,320 --> 00:03:32,960
and what kind of tokens it can ask to enter to issue.
109
00:03:32,960 --> 00:03:35,080
A token is a short-lived digital pass
110
00:03:35,080 --> 00:03:37,640
that lets software ask another service for access.
111
00:03:37,640 --> 00:03:39,280
The application registration also lists
112
00:03:39,280 --> 00:03:41,000
the permissions the app might want.
113
00:03:41,000 --> 00:03:43,520
For example, an app can ask to read calendar data,
114
00:03:43,520 --> 00:03:46,400
call Microsoft Graph, or access a business API.
115
00:03:46,400 --> 00:03:48,600
Microsoft Graph is Microsoft's main doorway for apps
116
00:03:48,600 --> 00:03:51,560
that need to work with Microsoft 365 data and services.
117
00:03:51,560 --> 00:03:52,560
But here's the key.
118
00:03:52,560 --> 00:03:54,840
The registration doesn't mean the app automatically
119
00:03:54,840 --> 00:03:56,880
gets every permission it asks for.
120
00:03:56,880 --> 00:03:59,640
It only describes the app and its possible requests.
121
00:03:59,640 --> 00:04:02,000
Picture a software company building a meeting app.
122
00:04:02,000 --> 00:04:04,680
They create one application registration for that app.
123
00:04:04,680 --> 00:04:06,480
Then many customer organizations can choose
124
00:04:06,480 --> 00:04:08,640
whether they trusted and allowed into their own
125
00:04:08,640 --> 00:04:09,480
entry directory.
126
00:04:09,480 --> 00:04:11,440
One app design can travel to many companies,
127
00:04:11,440 --> 00:04:12,720
but each company still decides
128
00:04:12,720 --> 00:04:14,800
what that app can do inside its own walls.
129
00:04:14,800 --> 00:04:16,960
That local decision happens through the service principle.
130
00:04:16,960 --> 00:04:19,280
A service principle is the app's local identity
131
00:04:19,280 --> 00:04:20,920
inside one entry directory.
132
00:04:20,920 --> 00:04:23,240
It's the record that receives permissions in your company
133
00:04:23,240 --> 00:04:25,880
and signs in as the app when the app works on its own.
134
00:04:25,880 --> 00:04:27,920
The filing cabinet comparison helps here.
135
00:04:27,920 --> 00:04:30,520
The application registration is the blank form design.
136
00:04:30,520 --> 00:04:33,360
It lists the fields and tells you what the form is for.
137
00:04:33,360 --> 00:04:35,240
The service principle is the completed folder
138
00:04:35,240 --> 00:04:37,200
inside your company's filing cabinet.
139
00:04:37,200 --> 00:04:39,640
Your company's details sit in that folder.
140
00:04:39,640 --> 00:04:42,360
Whether the app is allowed, which permissions it received,
141
00:04:42,360 --> 00:04:43,920
and which roles it can use.
142
00:04:43,920 --> 00:04:46,440
So a vendor can create one application registration
143
00:04:46,440 --> 00:04:49,040
for its software while your company gets its own service
144
00:04:49,040 --> 00:04:50,360
principle for that software.
145
00:04:50,360 --> 00:04:52,760
Another company gets a different service principle.
146
00:04:52,760 --> 00:04:54,520
Your decision doesn't give the app access
147
00:04:54,520 --> 00:04:56,200
in every company that uses it.
148
00:04:56,200 --> 00:04:58,400
Each organization controls its own local copy.
149
00:04:58,400 --> 00:04:59,960
That's the part people often miss.
150
00:04:59,960 --> 00:05:01,960
Say an app needs to read a shared mailbox.
151
00:05:01,960 --> 00:05:04,320
In your entry directory, its service principle
152
00:05:04,320 --> 00:05:06,280
can receive permission for that task.
153
00:05:06,280 --> 00:05:09,480
Or it may need to call Microsoft Graph to read a set of data.
154
00:05:09,480 --> 00:05:11,040
Or perhaps it needs an Azure role
155
00:05:11,040 --> 00:05:13,000
that lets it read from one storage account.
156
00:05:13,000 --> 00:05:14,960
Those permissions attach to the service principle
157
00:05:14,960 --> 00:05:16,120
in your organization.
158
00:05:16,120 --> 00:05:17,760
The app registration describes the app.
159
00:05:17,760 --> 00:05:19,800
The service principle does the work locally.
160
00:05:19,800 --> 00:05:22,120
Now let's add the third name, Managed Identity.
161
00:05:22,120 --> 00:05:24,680
A Managed Identity is a special type of service
162
00:05:24,680 --> 00:05:28,720
principle created and looked after by Azure for an Azure resource.
163
00:05:28,720 --> 00:05:31,240
That resource could be a virtual machine, an app service,
164
00:05:31,240 --> 00:05:32,920
an Azure Function or a logic app.
165
00:05:32,920 --> 00:05:35,280
Instead of your team creating an app registration,
166
00:05:35,280 --> 00:05:38,160
creating a secret, storing that secret, rotating it later,
167
00:05:38,160 --> 00:05:40,680
and hoping nobody copied it into the wrong place,
168
00:05:40,680 --> 00:05:43,600
Azure handles the identity credentials behind the scenes.
169
00:05:43,600 --> 00:05:45,880
Your Azure resource still gets an identity in entry.
170
00:05:45,880 --> 00:05:47,120
It can still receive permissions.
171
00:05:47,120 --> 00:05:49,920
But your developers don't need to carry around a password for it.
172
00:05:49,920 --> 00:05:52,240
There are two common Managed Identity patterns.
173
00:05:52,240 --> 00:05:55,880
A system assigned Managed Identity belongs to one Azure resource.
174
00:05:55,880 --> 00:05:57,840
Turn it on for a logic app, for example.
175
00:05:57,840 --> 00:06:00,400
An Azure creates an identity tied to that logic app.
176
00:06:00,400 --> 00:06:03,560
Delete the logic app and Azure removes that identity with it.
177
00:06:03,560 --> 00:06:06,440
That works well when one resource needs one identity.
178
00:06:06,440 --> 00:06:09,200
A user assigned Managed Identity has its own life
179
00:06:09,200 --> 00:06:10,720
outside a single resource.
180
00:06:10,720 --> 00:06:14,120
You create it, then attach it to the Azure resources
181
00:06:14,120 --> 00:06:15,200
that need to use it.
182
00:06:15,200 --> 00:06:18,400
For example, several app services might need the same approved access.
183
00:06:18,400 --> 00:06:21,000
Rather than setting up a separate identity for each one,
184
00:06:21,000 --> 00:06:23,800
you can attach the same user assigned Managed Identity
185
00:06:23,800 --> 00:06:25,160
to those chosen services.
186
00:06:25,160 --> 00:06:26,480
The difference is simple.
187
00:06:26,480 --> 00:06:30,600
System assigned means one resource, one identity linked together.
188
00:06:30,600 --> 00:06:32,760
User assigned means one identity that you can attach
189
00:06:32,760 --> 00:06:34,600
to more than one chosen Azure resource.
190
00:06:34,600 --> 00:06:36,800
So when you hear these names keep this map in your head,
191
00:06:36,800 --> 00:06:39,480
the application registration is the app's master design.
192
00:06:39,480 --> 00:06:42,520
The service principle is its working identity inside your company.
193
00:06:42,520 --> 00:06:44,640
A Managed Identity is a service principle
194
00:06:44,640 --> 00:06:47,400
that Azure creates and looks after for an Azure resource.
195
00:06:47,400 --> 00:06:49,400
It can sound like harmless naming detail
196
00:06:49,400 --> 00:06:51,440
until an app needs a database password.
197
00:06:51,440 --> 00:06:53,440
Then these differences decide whether that password
198
00:06:53,440 --> 00:06:57,240
ends up in a code file, a pipeline setting, or nowhere at all.
199
00:06:57,240 --> 00:07:00,080
Let's follow one normal request from an Azure workload
200
00:07:00,080 --> 00:07:02,840
asking for access to the service it needs.
201
00:07:02,840 --> 00:07:05,400
What a workload identity does during a request.
202
00:07:05,400 --> 00:07:07,360
Imagine a logic app that runs every morning
203
00:07:07,360 --> 00:07:09,640
and needs a password stored in Azure Key Vault.
204
00:07:09,640 --> 00:07:11,320
That password might belong to a database,
205
00:07:11,320 --> 00:07:13,040
a partner system, or an older service
206
00:07:13,040 --> 00:07:14,320
that still needs a password.
207
00:07:14,320 --> 00:07:16,520
The logic app needs the password to do its job.
208
00:07:16,520 --> 00:07:18,360
The old way creates an awkward problem.
209
00:07:18,360 --> 00:07:21,760
You put the database password inside the logic app workflow
210
00:07:21,760 --> 00:07:23,120
or in a connection setting.
211
00:07:23,120 --> 00:07:25,280
But now the workflow needs its own secret protected.
212
00:07:25,280 --> 00:07:28,200
Someone has to create it, copy it, store it, rotate it,
213
00:07:28,200 --> 00:07:31,480
and make sure it never lands in a code repository or a screenshot.
214
00:07:31,480 --> 00:07:33,880
You end up protecting a password with another password.
215
00:07:33,880 --> 00:07:35,840
A Managed Identity changes that path.
216
00:07:35,840 --> 00:07:38,040
The logic app starts and asks Entra ID
217
00:07:38,040 --> 00:07:39,800
for a short-lived access token.
218
00:07:39,800 --> 00:07:40,960
It doesn't type a password.
219
00:07:40,960 --> 00:07:42,640
It doesn't look up a client secret.
220
00:07:42,640 --> 00:07:44,360
Azure recognizes the Managed Identity
221
00:07:44,360 --> 00:07:47,320
connected to that logic app and handles the proof behind the scenes.
222
00:07:47,320 --> 00:07:48,920
Entra ID then checks two things.
223
00:07:48,920 --> 00:07:50,480
First, it checks the identity.
224
00:07:50,480 --> 00:07:53,120
Is this request really coming from the Managed Identity
225
00:07:53,120 --> 00:07:54,760
attached to this logic app?
226
00:07:54,760 --> 00:07:57,800
Second, it checks what that identity may request.
227
00:07:57,800 --> 00:08:00,080
Has the logic app received access to Key Vault?
228
00:08:00,080 --> 00:08:02,120
If the request passes those checks,
229
00:08:02,120 --> 00:08:04,520
Entra issues an access token for Key Vault.
230
00:08:04,520 --> 00:08:06,760
Think of that token as a temporary access pass
231
00:08:06,760 --> 00:08:08,280
created for a specific destination
232
00:08:08,280 --> 00:08:10,480
rather than a general pass that opens everything.
233
00:08:10,480 --> 00:08:12,400
The logic app sends that token to Key Vault.
234
00:08:12,400 --> 00:08:15,480
Key Vault reads the token and checks its own access rules.
235
00:08:15,480 --> 00:08:16,880
It asks a narrower question.
236
00:08:16,880 --> 00:08:19,480
May this identity read this specific secret?
237
00:08:19,480 --> 00:08:22,480
If the answer is yes, Key Vault returns the secret.
238
00:08:22,480 --> 00:08:24,600
If the answer is no, Key Vault blocks the request.
239
00:08:24,600 --> 00:08:26,520
That gives us two words that sound technical,
240
00:08:26,520 --> 00:08:29,040
but are easy once you separate them.
241
00:08:29,040 --> 00:08:31,240
Authentication answers, who is this?
242
00:08:31,240 --> 00:08:32,880
In our example, Authentication proves
243
00:08:32,880 --> 00:08:34,520
that the request comes from the logic apps
244
00:08:34,520 --> 00:08:35,760
managed identity.
245
00:08:35,760 --> 00:08:37,800
Authorization answers, what may it do?
246
00:08:37,800 --> 00:08:39,840
Authorization decides whether that logic app
247
00:08:39,840 --> 00:08:42,000
may read that particular secret from Key Vault.
248
00:08:42,000 --> 00:08:44,440
Those are separate checks and they need to stay separate.
249
00:08:44,440 --> 00:08:46,720
A workload can prove its identity perfectly
250
00:08:46,720 --> 00:08:48,320
and still get denied access.
251
00:08:48,320 --> 00:08:49,080
That isn't a fault.
252
00:08:49,080 --> 00:08:50,560
It means the boundaries work.
253
00:08:50,560 --> 00:08:52,760
This is where beginners often get tripped up.
254
00:08:52,760 --> 00:08:55,640
They turn on a managed identity, see that Azure created it,
255
00:08:55,640 --> 00:08:58,240
and expect the app to reach every service immediately.
256
00:08:58,240 --> 00:09:00,200
But an identity alone doesn't grant access.
257
00:09:00,200 --> 00:09:02,400
The logic app still needs a role or permission.
258
00:09:02,400 --> 00:09:05,520
Someone must allow that identity to read the required secret,
259
00:09:05,520 --> 00:09:08,320
use the required API or reach the required resource.
260
00:09:08,320 --> 00:09:10,120
Azure creates the badge, but you still decide
261
00:09:10,120 --> 00:09:11,720
which doors that badge opens.
262
00:09:11,720 --> 00:09:13,200
Compare that with the older setup.
263
00:09:13,200 --> 00:09:14,800
You may have a connection string that contains
264
00:09:14,800 --> 00:09:17,760
a server name, database name, user name, and password.
265
00:09:17,760 --> 00:09:20,320
You may have a client secret copied into an app setting.
266
00:09:20,320 --> 00:09:21,960
You may have a certificate stored somewhere
267
00:09:21,960 --> 00:09:23,720
that a build pipeline can reach.
268
00:09:23,720 --> 00:09:25,160
You may have the same password copied
269
00:09:25,160 --> 00:09:28,120
across several config files because one app talks to another.
270
00:09:28,120 --> 00:09:31,400
Each copy becomes another place to lose control.
271
00:09:31,400 --> 00:09:34,400
Someone changes the password and an overnight job stops working.
272
00:09:34,400 --> 00:09:36,200
Someone leaves a secret in a test file
273
00:09:36,200 --> 00:09:37,720
and it reaches source control.
274
00:09:37,720 --> 00:09:40,000
Someone finds a credential in an old pipeline
275
00:09:40,000 --> 00:09:41,840
and nobody knows whether it still works.
276
00:09:41,840 --> 00:09:43,560
With a managed identity, the logic app
277
00:09:43,560 --> 00:09:45,600
asks for a token when it needs one.
278
00:09:45,600 --> 00:09:47,640
The token expires after a short time.
279
00:09:47,640 --> 00:09:49,440
The logic app doesn't need to pose as a user
280
00:09:49,440 --> 00:09:51,720
and the developer doesn't need to keep a long-lived password
281
00:09:51,720 --> 00:09:52,960
beside the workflow.
282
00:09:52,960 --> 00:09:55,520
That doesn't mean the token carries unlimited power.
283
00:09:55,520 --> 00:09:58,280
A token only helps the workload reach the service
284
00:09:58,280 --> 00:10:00,720
it was issued for, and the service still checks
285
00:10:00,720 --> 00:10:02,880
the permissions assigned to that identity.
286
00:10:02,880 --> 00:10:04,640
A temporary pass with a narrow purpose
287
00:10:04,640 --> 00:10:07,480
is very different from handing out one permanent master password.
288
00:10:07,480 --> 00:10:10,120
So the modern flow solves a very practical problem.
289
00:10:10,120 --> 00:10:12,040
Software can access the right service
290
00:10:12,040 --> 00:10:14,240
without borrowing a human account or keeping a password
291
00:10:14,240 --> 00:10:17,920
in its own files, but that same access path can become dangerous
292
00:10:17,920 --> 00:10:19,840
when the identity has too much permission
293
00:10:19,840 --> 00:10:23,440
or when someone steals the way it proves who it is.
294
00:10:23,440 --> 00:10:26,080
Why workload identities need their own security rules?
295
00:10:26,080 --> 00:10:28,360
Now, tokens are cleaner than sharing passwords,
296
00:10:28,360 --> 00:10:31,320
but a workload identity still needs serious protection.
297
00:10:31,320 --> 00:10:33,480
Think of it like a robot that works in your office.
298
00:10:33,480 --> 00:10:36,200
It can't tap a proof on a phone or type a code.
299
00:10:36,200 --> 00:10:38,760
Some workloads run all day long, calling services,
300
00:10:38,760 --> 00:10:41,440
moving files, reading data, and deploying code
301
00:10:41,440 --> 00:10:43,080
while nobody watches the screen.
302
00:10:43,080 --> 00:10:45,480
In some cases, one app has access to more systems
303
00:10:45,480 --> 00:10:47,400
than a single employee ever needs.
304
00:10:47,400 --> 00:10:49,000
That creates a different kind of risk.
305
00:10:49,000 --> 00:10:51,240
You can ask a person to approve an MFA prompt
306
00:10:51,240 --> 00:10:54,000
or use a security key, an app can't do either.
307
00:10:54,000 --> 00:10:56,880
So an attacker doesn't try to trick the app into tapping a proof.
308
00:10:56,880 --> 00:10:58,600
They look for what the app uses instead
309
00:10:58,600 --> 00:11:00,800
that might be a client secret, it might be a certificate,
310
00:11:00,800 --> 00:11:02,760
it could be a stolen token or permissions
311
00:11:02,760 --> 00:11:05,040
that were far too broad from the start.
312
00:11:05,040 --> 00:11:07,080
Picture a developer setting up a new app registration
313
00:11:07,080 --> 00:11:08,680
for a small internal tool.
314
00:11:08,680 --> 00:11:11,680
They create a client secret, paste it into a config file,
315
00:11:11,680 --> 00:11:13,800
and add the same secret to a build pipeline
316
00:11:13,800 --> 00:11:15,600
so the app can deploy automatically.
317
00:11:15,600 --> 00:11:17,840
The tool works and everyone moves on.
318
00:11:17,840 --> 00:11:19,600
Months later, that config file ends up
319
00:11:19,600 --> 00:11:21,920
in a source code repository, or someone copies
320
00:11:21,920 --> 00:11:23,960
the pipeline settings into another project.
321
00:11:23,960 --> 00:11:26,200
Anyone who gets that secret can sign in as the app,
322
00:11:26,200 --> 00:11:30,160
not as themselves, until the secret expires or an admin removes it.
323
00:11:30,160 --> 00:11:31,760
Entrassies the request as the app.
324
00:11:31,760 --> 00:11:33,280
That's why a client secret deserves
325
00:11:33,280 --> 00:11:35,040
the same care as a powerful password,
326
00:11:35,040 --> 00:11:36,920
and why it should be the last choice
327
00:11:36,920 --> 00:11:38,800
when a better sign-in method exists.
328
00:11:38,800 --> 00:11:40,960
For a workload that runs inside Azure,
329
00:11:40,960 --> 00:11:44,000
start with a managed identity when the service supports it.
330
00:11:44,000 --> 00:11:47,200
For code that runs outside Azure like a GitHub actions pipeline,
331
00:11:47,200 --> 00:11:49,520
look at workload identity federation.
332
00:11:49,520 --> 00:11:52,280
That phrase sounds complicated, but the idea is simple.
333
00:11:52,280 --> 00:11:54,400
GitHub can prove which workflow is running,
334
00:11:54,400 --> 00:11:55,960
which repository it came from,
335
00:11:55,960 --> 00:11:57,880
and under what conditions it started.
336
00:11:57,880 --> 00:12:00,120
Entrassed that proof for a defined setup,
337
00:12:00,120 --> 00:12:02,600
then issues a short-lived token to the pipeline.
338
00:12:02,600 --> 00:12:06,800
No long-lived entry secret needs to sit in GitHub waiting to be copied.
339
00:12:06,800 --> 00:12:08,280
If neither managed identity,
340
00:12:08,280 --> 00:12:10,040
no federation works for your app,
341
00:12:10,040 --> 00:12:12,880
a certificate is usually a better choice than a client secret.
342
00:12:12,880 --> 00:12:15,960
Certificates still need safe storage and planned renewal,
343
00:12:15,960 --> 00:12:19,400
but they're harder to casually copy and use than a plain-text secret.
344
00:12:19,400 --> 00:12:22,160
Client secrets still exist because some older apps need them.
345
00:12:22,160 --> 00:12:24,360
Treat them as an exception, not the default.
346
00:12:24,360 --> 00:12:25,760
The next control is permission.
347
00:12:25,760 --> 00:12:28,720
An identity should receive only what its job requires.
348
00:12:28,720 --> 00:12:30,960
If a reporting app needs one SharePoint folder,
349
00:12:30,960 --> 00:12:32,560
don't give it access to every site.
350
00:12:32,560 --> 00:12:34,760
If a workload needs one secret from Key Vault,
351
00:12:34,760 --> 00:12:36,880
don't give it permission to read every secret.
352
00:12:36,880 --> 00:12:39,360
If a pipeline deploys to one Azure resource group,
353
00:12:39,360 --> 00:12:42,120
don't hand it owner access across the whole subscription.
354
00:12:42,120 --> 00:12:43,920
Broad access feels easy during setup,
355
00:12:43,920 --> 00:12:47,320
but it also turns one stolen identity into a much larger incident.
356
00:12:47,320 --> 00:12:49,640
Microsoft Entra can apply conditional access
357
00:12:49,640 --> 00:12:51,120
to workload identities too.
358
00:12:51,120 --> 00:12:53,520
These are rules, Entra checks when it issues a token.
359
00:12:53,520 --> 00:12:55,840
For example, a policy can limit a workload
360
00:12:55,840 --> 00:12:58,440
to expected locations or respond to risk signals.
361
00:12:58,440 --> 00:13:00,200
The app won't get an MFA prompt,
362
00:13:00,200 --> 00:13:02,240
but Entra can still decide whether the conditions
363
00:13:02,240 --> 00:13:04,240
around that request look acceptable.
364
00:13:04,240 --> 00:13:05,560
Logs matter just as much.
365
00:13:05,560 --> 00:13:08,600
Review workload sign-ins, watch for repeated failures,
366
00:13:08,600 --> 00:13:10,600
access from an unexpected location,
367
00:13:10,600 --> 00:13:12,320
sudden activity at odd times,
368
00:13:12,320 --> 00:13:15,480
or an app calling services it normally never touches.
369
00:13:15,480 --> 00:13:17,520
Microsoft Entra ID protection can help surface
370
00:13:17,520 --> 00:13:19,000
risky workload activity,
371
00:13:19,000 --> 00:13:20,880
but a tool can't decide whether an old app
372
00:13:20,880 --> 00:13:22,280
still has a business purpose.
373
00:13:22,280 --> 00:13:23,680
A person needs to own that answer.
374
00:13:23,680 --> 00:13:26,160
Every workload identity needs a named owner.
375
00:13:26,160 --> 00:13:27,800
That owner should know why it exists,
376
00:13:27,800 --> 00:13:29,440
what it can access, how it signs in,
377
00:13:29,440 --> 00:13:31,320
and when somebody will review it again.
378
00:13:31,320 --> 00:13:32,360
When the app disappears,
379
00:13:32,360 --> 00:13:34,760
its identity and permissions should disappear too.
380
00:13:34,760 --> 00:13:37,880
Many companies treat app security as a one time setup task,
381
00:13:37,880 --> 00:13:40,160
create the service principle, grant access,
382
00:13:40,160 --> 00:13:42,480
confirm the app works, and forget about it.
383
00:13:42,480 --> 00:13:44,200
But old projects don't clean themselves up,
384
00:13:44,200 --> 00:13:47,160
an unused service principle can keep permissions for years.
385
00:13:47,160 --> 00:13:49,600
A forgotten certificate can remain valid.
386
00:13:49,600 --> 00:13:51,240
A former team may leave behind automation
387
00:13:51,240 --> 00:13:52,200
that nobody can explain,
388
00:13:52,200 --> 00:13:54,680
yet nobody wants to disable because something might break.
389
00:13:54,680 --> 00:13:56,080
That uncertainty is the risk,
390
00:13:56,080 --> 00:13:58,120
so you don't need to memorize every enter setting.
391
00:13:58,120 --> 00:14:00,080
You need a simple way to choose the right pattern
392
00:14:00,080 --> 00:14:03,200
then check access before a workload goes live.
393
00:14:03,200 --> 00:14:05,400
Picking the right pattern without overthinking it,
394
00:14:05,400 --> 00:14:07,960
you don't need to turn this into a big architecture project.
395
00:14:07,960 --> 00:14:10,640
Start with one question, where does the workload run?
396
00:14:10,640 --> 00:14:12,120
If it runs inside Azure,
397
00:14:12,120 --> 00:14:15,040
on a virtual machine app service, function, or logic app,
398
00:14:15,040 --> 00:14:17,160
start by checking for a managed identity.
399
00:14:17,160 --> 00:14:18,840
Turn it on, then give that identity
400
00:14:18,840 --> 00:14:21,840
the smallest role or permission the workload needs.
401
00:14:21,840 --> 00:14:24,760
A function that only reads blobs from one storage account
402
00:14:24,760 --> 00:14:26,800
should get access to that storage account,
403
00:14:26,800 --> 00:14:29,680
not every storage account in the subscription.
404
00:14:29,680 --> 00:14:32,240
A logic app that needs one key vault secret
405
00:14:32,240 --> 00:14:34,840
should receive access to that secret, not the whole vault.
406
00:14:34,840 --> 00:14:36,520
The location of the code tells you a lot.
407
00:14:36,520 --> 00:14:38,160
If the code runs outside Azure,
408
00:14:38,160 --> 00:14:40,800
perhaps in GitHub Actions or another Cloud Platform,
409
00:14:40,800 --> 00:14:42,800
look for workload identity federation.
410
00:14:42,800 --> 00:14:44,520
The outside platform proves what it is
411
00:14:44,520 --> 00:14:46,040
using its own trusted token.
412
00:14:46,040 --> 00:14:47,080
Entra checks that trust,
413
00:14:47,080 --> 00:14:49,400
then gives the workload a short-lived enter token.
414
00:14:49,400 --> 00:14:50,760
That lets a pipeline deploy
415
00:14:50,760 --> 00:14:54,200
without keeping a long-lived secret in the pipeline settings.
416
00:14:54,200 --> 00:14:56,120
The third question applies to custom apps.
417
00:14:56,120 --> 00:14:58,120
Does the app need to sign in as itself,
418
00:14:58,120 --> 00:15:00,160
work across more than one organization,
419
00:15:00,160 --> 00:15:03,000
or request app permissions for Microsoft 365,
420
00:15:03,000 --> 00:15:04,840
or another Entra protected service?
421
00:15:04,840 --> 00:15:07,240
If yes, you'll usually use an application registration
422
00:15:07,240 --> 00:15:08,560
and a service principal.
423
00:15:08,560 --> 00:15:10,480
The application registration describes the app.
424
00:15:10,480 --> 00:15:13,600
The service principal receives access inside each organization,
425
00:15:13,600 --> 00:15:14,720
where the app runs.
426
00:15:14,720 --> 00:15:16,200
When that app needs a credential,
427
00:15:16,200 --> 00:15:19,200
choose a certificate over a client secret where you can.
428
00:15:19,200 --> 00:15:21,360
A certificate still needs careful handling,
429
00:15:21,360 --> 00:15:22,680
but it gives you a stronger option
430
00:15:22,680 --> 00:15:25,800
than a plain text secret copied between people and systems.
431
00:15:25,800 --> 00:15:27,400
Think about a simple file scenario.
432
00:15:27,400 --> 00:15:30,080
Your personal work files usually begin in one drive.
433
00:15:30,080 --> 00:15:31,720
Team files usually live in SharePoint,
434
00:15:31,720 --> 00:15:33,240
that tells you where the files belong,
435
00:15:33,240 --> 00:15:35,760
but it doesn't give an app access to either place.
436
00:15:35,760 --> 00:15:38,080
The app still needs its own Entra identity.
437
00:15:38,080 --> 00:15:39,800
Then you decide whether it can read a folder,
438
00:15:39,800 --> 00:15:41,680
upload a file, or do nothing at all.
439
00:15:41,680 --> 00:15:44,520
File location and app access are separate decisions.
440
00:15:44,520 --> 00:15:46,000
Before any workload goes live,
441
00:15:46,000 --> 00:15:48,360
ask five plain questions, who owns this identity,
442
00:15:48,360 --> 00:15:50,040
what can it access, how does it sign in,
443
00:15:50,040 --> 00:15:51,560
where will someone review its logs,
444
00:15:51,560 --> 00:15:53,160
and when will its access be removed?
445
00:15:53,160 --> 00:15:54,880
Those questions work for a brand new app,
446
00:15:54,880 --> 00:15:57,360
but they also expose risk in apps already sitting
447
00:15:57,360 --> 00:15:58,280
in your directory.
448
00:15:58,280 --> 00:16:00,160
An old service principle with no owner,
449
00:16:00,160 --> 00:16:01,920
a client secret nobody remembers,
450
00:16:01,920 --> 00:16:04,200
and broad permissions nobody can explain should not stay
451
00:16:04,200 --> 00:16:05,960
invisible just because the app still exists.
452
00:16:05,960 --> 00:16:08,240
You don't need an admin deep dive to begin,
453
00:16:08,240 --> 00:16:09,520
you need an inventory,
454
00:16:09,520 --> 00:16:12,600
and a willingness to ask what each workload is doing.
455
00:16:12,600 --> 00:16:15,320
So how do you do a workload identity check?
456
00:16:15,320 --> 00:16:17,160
Start by listing all your applications,
457
00:16:17,160 --> 00:16:19,600
service principles, and managed identities,
458
00:16:19,600 --> 00:16:21,560
then attach a real owner to every single one.
459
00:16:21,560 --> 00:16:22,480
That's step one.
460
00:16:22,480 --> 00:16:24,720
Next, hunt for client secrets hiding in code,
461
00:16:24,720 --> 00:16:26,560
config files, and build pipelines.
462
00:16:26,560 --> 00:16:28,880
If an Azure workload can use a managed identity,
463
00:16:28,880 --> 00:16:31,560
move it in that direction, then review permissions,
464
00:16:31,560 --> 00:16:33,720
remove any identities nobody uses,
465
00:16:33,720 --> 00:16:35,640
and watch the sign in logs for activity
466
00:16:35,640 --> 00:16:36,880
that doesn't fit the job.
467
00:16:36,880 --> 00:16:39,880
An unattended app can still open doors across your company,
468
00:16:39,880 --> 00:16:41,120
treated with the same care,
469
00:16:41,120 --> 00:16:42,840
you'd give a highly privileged account.
00:00:00,000 --> 00:00:02,280
You already know how your own work account works.
2
00:00:02,280 --> 00:00:04,440
You sign in with a password or maybe Windows Hello,
3
00:00:04,440 --> 00:00:06,640
approve an MFA prompt and if you forget your password,
4
00:00:06,640 --> 00:00:07,480
you reset it.
5
00:00:07,480 --> 00:00:09,960
But software needs access too and nobody sits at a keyboard
6
00:00:09,960 --> 00:00:11,800
to approve a prompt for a running app.
7
00:00:11,800 --> 00:00:13,600
So a logic app might need to read a mailbox
8
00:00:13,600 --> 00:00:16,520
at two in the morning or an app might need to reach a database
9
00:00:16,520 --> 00:00:18,520
or a backup job might need to save files
10
00:00:18,520 --> 00:00:19,520
while everyone is asleep.
11
00:00:19,520 --> 00:00:20,360
So who is signing in?
12
00:00:20,360 --> 00:00:23,520
And that brings us to Microsoft Entra Workload Identities.
13
00:00:23,520 --> 00:00:24,600
By the end of this episode,
14
00:00:24,600 --> 00:00:27,640
you'll have a plain English map of user identities,
15
00:00:27,640 --> 00:00:31,000
workload identities, app registrations, service principles,
16
00:00:31,000 --> 00:00:32,400
and managed identities.
17
00:00:32,400 --> 00:00:34,600
This matters because old apps often hide passwords
18
00:00:34,600 --> 00:00:36,840
in code, config files, or build pipelines.
19
00:00:36,840 --> 00:00:39,720
Some have broad access, some have no clear owner at all.
20
00:00:39,720 --> 00:00:40,920
And the safer choice often means
21
00:00:40,920 --> 00:00:43,360
the developer never handles a password in the first place.
22
00:00:43,360 --> 00:00:45,880
Let's start with the identity you already use every day
23
00:00:45,880 --> 00:00:48,240
then compare it with the one that software uses.
24
00:00:48,240 --> 00:00:50,480
User identities and workload identities.
25
00:00:50,480 --> 00:00:52,480
People and software both need access
26
00:00:52,480 --> 00:00:54,800
but they prove who they are in very different ways.
27
00:00:54,800 --> 00:00:56,800
Your user identity is your digital badge.
28
00:00:56,800 --> 00:00:58,800
It connects to your name, your work account,
29
00:00:58,800 --> 00:01:00,480
your groups, and the job you do.
30
00:01:00,480 --> 00:01:02,440
When you sign into Outlook Teams, SharePoint,
31
00:01:02,440 --> 00:01:05,320
or another Work app, Microsoft Entra checks that badge.
32
00:01:05,320 --> 00:01:06,920
You might use a password, your phone,
33
00:01:06,920 --> 00:01:08,680
a security key, or Windows Hello.
34
00:01:08,680 --> 00:01:10,160
Then MFA adds another check.
35
00:01:10,160 --> 00:01:12,640
Entra asks, "Is this really Mirko or someone pretending
36
00:01:12,640 --> 00:01:13,560
to be Mirko?"
37
00:01:13,560 --> 00:01:15,480
That works because there is a person at the other end
38
00:01:15,480 --> 00:01:17,840
who can type a code, tap approve, or use a fingerprint,
39
00:01:17,840 --> 00:01:18,640
or face.
40
00:01:18,640 --> 00:01:20,200
A workload identity is different.
41
00:01:20,200 --> 00:01:22,040
It's a digital badge for software.
42
00:01:22,040 --> 00:01:23,760
That software could be an app your team built
43
00:01:23,760 --> 00:01:25,400
an automation that runs on a schedule,
44
00:01:25,400 --> 00:01:27,680
a background service, or even an AI agent
45
00:01:27,680 --> 00:01:30,400
that needs access to company data for a defined job.
46
00:01:30,400 --> 00:01:30,920
Here's the thing.
47
00:01:30,920 --> 00:01:33,480
Think of Microsoft Entra ID as the reception desk
48
00:01:33,480 --> 00:01:35,080
in a modern office building.
49
00:01:35,080 --> 00:01:37,360
When you enter the building, you show your personal badge
50
00:01:37,360 --> 00:01:40,520
so reception can see who you are, which teams you belong to,
51
00:01:40,520 --> 00:01:42,640
and which rooms you may enter.
52
00:01:42,640 --> 00:01:44,960
A workload enters with a badge assigned to its job,
53
00:01:44,960 --> 00:01:46,840
not to a person.
54
00:01:46,840 --> 00:01:49,120
The logic app badge might say, "I send an alert
55
00:01:49,120 --> 00:01:50,880
when a support request arrives."
56
00:01:50,880 --> 00:01:52,440
A virtual machine badge might say,
57
00:01:52,440 --> 00:01:54,960
"I can read one secret from the company vault."
58
00:01:54,960 --> 00:01:56,400
A backup service badge might say,
59
00:01:56,400 --> 00:01:58,440
"I can write backup files to this location."
60
00:01:58,440 --> 00:02:00,280
And a GitHub pipeline badge might say,
61
00:02:00,280 --> 00:02:02,120
"I can deploy this approved piece of code
62
00:02:02,120 --> 00:02:04,080
into this Azure resource group."
63
00:02:04,080 --> 00:02:06,480
Each workload needs access for a reason.
64
00:02:06,480 --> 00:02:08,040
Giving each one its own identity,
65
00:02:08,040 --> 00:02:10,520
let's enter check that reason, recorded silence,
66
00:02:10,520 --> 00:02:11,960
and control what it can reach.
67
00:02:11,960 --> 00:02:13,440
You've probably seen the older approach,
68
00:02:13,440 --> 00:02:15,120
someone creates a normal user account
69
00:02:15,120 --> 00:02:16,880
like service account at company.
70
00:02:16,880 --> 00:02:18,960
Come gives it a password, maybe a mailbox,
71
00:02:18,960 --> 00:02:21,240
maybe brought permissions, and then several apps share it.
72
00:02:21,240 --> 00:02:23,840
That creates a mess, which app used the account last night
73
00:02:23,840 --> 00:02:26,400
who owns the password, what breaks if you disable it?
74
00:02:26,400 --> 00:02:27,920
And if someone copies that password,
75
00:02:27,920 --> 00:02:29,840
can they act as every app that shares it?
76
00:02:29,840 --> 00:02:31,560
A workload identity fixes that model.
77
00:02:31,560 --> 00:02:32,960
It doesn't pretend to be a person,
78
00:02:32,960 --> 00:02:35,800
it gets its own permissions and its own sign-in records.
79
00:02:35,800 --> 00:02:37,760
That separation gives you a much clearer answer
80
00:02:37,760 --> 00:02:38,880
when something goes wrong.
81
00:02:38,880 --> 00:02:41,240
Now, there is one limit you need to keep in mind.
82
00:02:41,240 --> 00:02:43,560
A workload identity can't complete an MFA prompt
83
00:02:43,560 --> 00:02:45,720
because an app can't pull out a phone and tap approve.
84
00:02:45,720 --> 00:02:47,000
So you protect it in other ways,
85
00:02:47,000 --> 00:02:48,840
like controlling what it can access,
86
00:02:48,840 --> 00:02:51,560
how it proves its identity, and where its silence come from.
87
00:02:51,560 --> 00:02:52,640
People use personal badges
88
00:02:52,640 --> 00:02:54,880
because people work in many places and make choices.
89
00:02:54,880 --> 00:02:56,360
Software uses job badges
90
00:02:56,360 --> 00:02:58,960
because software should perform a narrow task repeatedly
91
00:02:58,960 --> 00:03:00,720
without borrowing a human account.
92
00:03:00,720 --> 00:03:02,520
Once you give software its own badge though,
93
00:03:02,520 --> 00:03:03,880
Enter starts using several names
94
00:03:03,880 --> 00:03:05,560
that sound almost identical.
95
00:03:05,560 --> 00:03:08,240
And that's where most beginners get stuck.
96
00:03:08,240 --> 00:03:10,360
The three names that confuse everyone.
97
00:03:10,360 --> 00:03:12,760
You'll see three names in Enter over and over.
98
00:03:12,760 --> 00:03:15,400
Application registration, service principle,
99
00:03:15,400 --> 00:03:16,800
and managed identity.
100
00:03:16,800 --> 00:03:18,680
They all connect, but they're not the same thing.
101
00:03:18,680 --> 00:03:20,480
Let's start with application registration.
102
00:03:20,480 --> 00:03:22,000
Think of an application registration
103
00:03:22,000 --> 00:03:23,880
as the master record for an app.
104
00:03:23,880 --> 00:03:25,400
It's like the design sheet created
105
00:03:25,400 --> 00:03:27,280
before the app ever enters a company.
106
00:03:27,280 --> 00:03:28,640
It describes the app's name,
107
00:03:28,640 --> 00:03:30,320
where it sends people after sign in,
108
00:03:30,320 --> 00:03:32,960
and what kind of tokens it can ask to enter to issue.
109
00:03:32,960 --> 00:03:35,080
A token is a short-lived digital pass
110
00:03:35,080 --> 00:03:37,640
that lets software ask another service for access.
111
00:03:37,640 --> 00:03:39,280
The application registration also lists
112
00:03:39,280 --> 00:03:41,000
the permissions the app might want.
113
00:03:41,000 --> 00:03:43,520
For example, an app can ask to read calendar data,
114
00:03:43,520 --> 00:03:46,400
call Microsoft Graph, or access a business API.
115
00:03:46,400 --> 00:03:48,600
Microsoft Graph is Microsoft's main doorway for apps
116
00:03:48,600 --> 00:03:51,560
that need to work with Microsoft 365 data and services.
117
00:03:51,560 --> 00:03:52,560
But here's the key.
118
00:03:52,560 --> 00:03:54,840
The registration doesn't mean the app automatically
119
00:03:54,840 --> 00:03:56,880
gets every permission it asks for.
120
00:03:56,880 --> 00:03:59,640
It only describes the app and its possible requests.
121
00:03:59,640 --> 00:04:02,000
Picture a software company building a meeting app.
122
00:04:02,000 --> 00:04:04,680
They create one application registration for that app.
123
00:04:04,680 --> 00:04:06,480
Then many customer organizations can choose
124
00:04:06,480 --> 00:04:08,640
whether they trusted and allowed into their own
125
00:04:08,640 --> 00:04:09,480
entry directory.
126
00:04:09,480 --> 00:04:11,440
One app design can travel to many companies,
127
00:04:11,440 --> 00:04:12,720
but each company still decides
128
00:04:12,720 --> 00:04:14,800
what that app can do inside its own walls.
129
00:04:14,800 --> 00:04:16,960
That local decision happens through the service principle.
130
00:04:16,960 --> 00:04:19,280
A service principle is the app's local identity
131
00:04:19,280 --> 00:04:20,920
inside one entry directory.
132
00:04:20,920 --> 00:04:23,240
It's the record that receives permissions in your company
133
00:04:23,240 --> 00:04:25,880
and signs in as the app when the app works on its own.
134
00:04:25,880 --> 00:04:27,920
The filing cabinet comparison helps here.
135
00:04:27,920 --> 00:04:30,520
The application registration is the blank form design.
136
00:04:30,520 --> 00:04:33,360
It lists the fields and tells you what the form is for.
137
00:04:33,360 --> 00:04:35,240
The service principle is the completed folder
138
00:04:35,240 --> 00:04:37,200
inside your company's filing cabinet.
139
00:04:37,200 --> 00:04:39,640
Your company's details sit in that folder.
140
00:04:39,640 --> 00:04:42,360
Whether the app is allowed, which permissions it received,
141
00:04:42,360 --> 00:04:43,920
and which roles it can use.
142
00:04:43,920 --> 00:04:46,440
So a vendor can create one application registration
143
00:04:46,440 --> 00:04:49,040
for its software while your company gets its own service
144
00:04:49,040 --> 00:04:50,360
principle for that software.
145
00:04:50,360 --> 00:04:52,760
Another company gets a different service principle.
146
00:04:52,760 --> 00:04:54,520
Your decision doesn't give the app access
147
00:04:54,520 --> 00:04:56,200
in every company that uses it.
148
00:04:56,200 --> 00:04:58,400
Each organization controls its own local copy.
149
00:04:58,400 --> 00:04:59,960
That's the part people often miss.
150
00:04:59,960 --> 00:05:01,960
Say an app needs to read a shared mailbox.
151
00:05:01,960 --> 00:05:04,320
In your entry directory, its service principle
152
00:05:04,320 --> 00:05:06,280
can receive permission for that task.
153
00:05:06,280 --> 00:05:09,480
Or it may need to call Microsoft Graph to read a set of data.
154
00:05:09,480 --> 00:05:11,040
Or perhaps it needs an Azure role
155
00:05:11,040 --> 00:05:13,000
that lets it read from one storage account.
156
00:05:13,000 --> 00:05:14,960
Those permissions attach to the service principle
157
00:05:14,960 --> 00:05:16,120
in your organization.
158
00:05:16,120 --> 00:05:17,760
The app registration describes the app.
159
00:05:17,760 --> 00:05:19,800
The service principle does the work locally.
160
00:05:19,800 --> 00:05:22,120
Now let's add the third name, Managed Identity.
161
00:05:22,120 --> 00:05:24,680
A Managed Identity is a special type of service
162
00:05:24,680 --> 00:05:28,720
principle created and looked after by Azure for an Azure resource.
163
00:05:28,720 --> 00:05:31,240
That resource could be a virtual machine, an app service,
164
00:05:31,240 --> 00:05:32,920
an Azure Function or a logic app.
165
00:05:32,920 --> 00:05:35,280
Instead of your team creating an app registration,
166
00:05:35,280 --> 00:05:38,160
creating a secret, storing that secret, rotating it later,
167
00:05:38,160 --> 00:05:40,680
and hoping nobody copied it into the wrong place,
168
00:05:40,680 --> 00:05:43,600
Azure handles the identity credentials behind the scenes.
169
00:05:43,600 --> 00:05:45,880
Your Azure resource still gets an identity in entry.
170
00:05:45,880 --> 00:05:47,120
It can still receive permissions.
171
00:05:47,120 --> 00:05:49,920
But your developers don't need to carry around a password for it.
172
00:05:49,920 --> 00:05:52,240
There are two common Managed Identity patterns.
173
00:05:52,240 --> 00:05:55,880
A system assigned Managed Identity belongs to one Azure resource.
174
00:05:55,880 --> 00:05:57,840
Turn it on for a logic app, for example.
175
00:05:57,840 --> 00:06:00,400
An Azure creates an identity tied to that logic app.
176
00:06:00,400 --> 00:06:03,560
Delete the logic app and Azure removes that identity with it.
177
00:06:03,560 --> 00:06:06,440
That works well when one resource needs one identity.
178
00:06:06,440 --> 00:06:09,200
A user assigned Managed Identity has its own life
179
00:06:09,200 --> 00:06:10,720
outside a single resource.
180
00:06:10,720 --> 00:06:14,120
You create it, then attach it to the Azure resources
181
00:06:14,120 --> 00:06:15,200
that need to use it.
182
00:06:15,200 --> 00:06:18,400
For example, several app services might need the same approved access.
183
00:06:18,400 --> 00:06:21,000
Rather than setting up a separate identity for each one,
184
00:06:21,000 --> 00:06:23,800
you can attach the same user assigned Managed Identity
185
00:06:23,800 --> 00:06:25,160
to those chosen services.
186
00:06:25,160 --> 00:06:26,480
The difference is simple.
187
00:06:26,480 --> 00:06:30,600
System assigned means one resource, one identity linked together.
188
00:06:30,600 --> 00:06:32,760
User assigned means one identity that you can attach
189
00:06:32,760 --> 00:06:34,600
to more than one chosen Azure resource.
190
00:06:34,600 --> 00:06:36,800
So when you hear these names keep this map in your head,
191
00:06:36,800 --> 00:06:39,480
the application registration is the app's master design.
192
00:06:39,480 --> 00:06:42,520
The service principle is its working identity inside your company.
193
00:06:42,520 --> 00:06:44,640
A Managed Identity is a service principle
194
00:06:44,640 --> 00:06:47,400
that Azure creates and looks after for an Azure resource.
195
00:06:47,400 --> 00:06:49,400
It can sound like harmless naming detail
196
00:06:49,400 --> 00:06:51,440
until an app needs a database password.
197
00:06:51,440 --> 00:06:53,440
Then these differences decide whether that password
198
00:06:53,440 --> 00:06:57,240
ends up in a code file, a pipeline setting, or nowhere at all.
199
00:06:57,240 --> 00:07:00,080
Let's follow one normal request from an Azure workload
200
00:07:00,080 --> 00:07:02,840
asking for access to the service it needs.
201
00:07:02,840 --> 00:07:05,400
What a workload identity does during a request.
202
00:07:05,400 --> 00:07:07,360
Imagine a logic app that runs every morning
203
00:07:07,360 --> 00:07:09,640
and needs a password stored in Azure Key Vault.
204
00:07:09,640 --> 00:07:11,320
That password might belong to a database,
205
00:07:11,320 --> 00:07:13,040
a partner system, or an older service
206
00:07:13,040 --> 00:07:14,320
that still needs a password.
207
00:07:14,320 --> 00:07:16,520
The logic app needs the password to do its job.
208
00:07:16,520 --> 00:07:18,360
The old way creates an awkward problem.
209
00:07:18,360 --> 00:07:21,760
You put the database password inside the logic app workflow
210
00:07:21,760 --> 00:07:23,120
or in a connection setting.
211
00:07:23,120 --> 00:07:25,280
But now the workflow needs its own secret protected.
212
00:07:25,280 --> 00:07:28,200
Someone has to create it, copy it, store it, rotate it,
213
00:07:28,200 --> 00:07:31,480
and make sure it never lands in a code repository or a screenshot.
214
00:07:31,480 --> 00:07:33,880
You end up protecting a password with another password.
215
00:07:33,880 --> 00:07:35,840
A Managed Identity changes that path.
216
00:07:35,840 --> 00:07:38,040
The logic app starts and asks Entra ID
217
00:07:38,040 --> 00:07:39,800
for a short-lived access token.
218
00:07:39,800 --> 00:07:40,960
It doesn't type a password.
219
00:07:40,960 --> 00:07:42,640
It doesn't look up a client secret.
220
00:07:42,640 --> 00:07:44,360
Azure recognizes the Managed Identity
221
00:07:44,360 --> 00:07:47,320
connected to that logic app and handles the proof behind the scenes.
222
00:07:47,320 --> 00:07:48,920
Entra ID then checks two things.
223
00:07:48,920 --> 00:07:50,480
First, it checks the identity.
224
00:07:50,480 --> 00:07:53,120
Is this request really coming from the Managed Identity
225
00:07:53,120 --> 00:07:54,760
attached to this logic app?
226
00:07:54,760 --> 00:07:57,800
Second, it checks what that identity may request.
227
00:07:57,800 --> 00:08:00,080
Has the logic app received access to Key Vault?
228
00:08:00,080 --> 00:08:02,120
If the request passes those checks,
229
00:08:02,120 --> 00:08:04,520
Entra issues an access token for Key Vault.
230
00:08:04,520 --> 00:08:06,760
Think of that token as a temporary access pass
231
00:08:06,760 --> 00:08:08,280
created for a specific destination
232
00:08:08,280 --> 00:08:10,480
rather than a general pass that opens everything.
233
00:08:10,480 --> 00:08:12,400
The logic app sends that token to Key Vault.
234
00:08:12,400 --> 00:08:15,480
Key Vault reads the token and checks its own access rules.
235
00:08:15,480 --> 00:08:16,880
It asks a narrower question.
236
00:08:16,880 --> 00:08:19,480
May this identity read this specific secret?
237
00:08:19,480 --> 00:08:22,480
If the answer is yes, Key Vault returns the secret.
238
00:08:22,480 --> 00:08:24,600
If the answer is no, Key Vault blocks the request.
239
00:08:24,600 --> 00:08:26,520
That gives us two words that sound technical,
240
00:08:26,520 --> 00:08:29,040
but are easy once you separate them.
241
00:08:29,040 --> 00:08:31,240
Authentication answers, who is this?
242
00:08:31,240 --> 00:08:32,880
In our example, Authentication proves
243
00:08:32,880 --> 00:08:34,520
that the request comes from the logic apps
244
00:08:34,520 --> 00:08:35,760
managed identity.
245
00:08:35,760 --> 00:08:37,800
Authorization answers, what may it do?
246
00:08:37,800 --> 00:08:39,840
Authorization decides whether that logic app
247
00:08:39,840 --> 00:08:42,000
may read that particular secret from Key Vault.
248
00:08:42,000 --> 00:08:44,440
Those are separate checks and they need to stay separate.
249
00:08:44,440 --> 00:08:46,720
A workload can prove its identity perfectly
250
00:08:46,720 --> 00:08:48,320
and still get denied access.
251
00:08:48,320 --> 00:08:49,080
That isn't a fault.
252
00:08:49,080 --> 00:08:50,560
It means the boundaries work.
253
00:08:50,560 --> 00:08:52,760
This is where beginners often get tripped up.
254
00:08:52,760 --> 00:08:55,640
They turn on a managed identity, see that Azure created it,
255
00:08:55,640 --> 00:08:58,240
and expect the app to reach every service immediately.
256
00:08:58,240 --> 00:09:00,200
But an identity alone doesn't grant access.
257
00:09:00,200 --> 00:09:02,400
The logic app still needs a role or permission.
258
00:09:02,400 --> 00:09:05,520
Someone must allow that identity to read the required secret,
259
00:09:05,520 --> 00:09:08,320
use the required API or reach the required resource.
260
00:09:08,320 --> 00:09:10,120
Azure creates the badge, but you still decide
261
00:09:10,120 --> 00:09:11,720
which doors that badge opens.
262
00:09:11,720 --> 00:09:13,200
Compare that with the older setup.
263
00:09:13,200 --> 00:09:14,800
You may have a connection string that contains
264
00:09:14,800 --> 00:09:17,760
a server name, database name, user name, and password.
265
00:09:17,760 --> 00:09:20,320
You may have a client secret copied into an app setting.
266
00:09:20,320 --> 00:09:21,960
You may have a certificate stored somewhere
267
00:09:21,960 --> 00:09:23,720
that a build pipeline can reach.
268
00:09:23,720 --> 00:09:25,160
You may have the same password copied
269
00:09:25,160 --> 00:09:28,120
across several config files because one app talks to another.
270
00:09:28,120 --> 00:09:31,400
Each copy becomes another place to lose control.
271
00:09:31,400 --> 00:09:34,400
Someone changes the password and an overnight job stops working.
272
00:09:34,400 --> 00:09:36,200
Someone leaves a secret in a test file
273
00:09:36,200 --> 00:09:37,720
and it reaches source control.
274
00:09:37,720 --> 00:09:40,000
Someone finds a credential in an old pipeline
275
00:09:40,000 --> 00:09:41,840
and nobody knows whether it still works.
276
00:09:41,840 --> 00:09:43,560
With a managed identity, the logic app
277
00:09:43,560 --> 00:09:45,600
asks for a token when it needs one.
278
00:09:45,600 --> 00:09:47,640
The token expires after a short time.
279
00:09:47,640 --> 00:09:49,440
The logic app doesn't need to pose as a user
280
00:09:49,440 --> 00:09:51,720
and the developer doesn't need to keep a long-lived password
281
00:09:51,720 --> 00:09:52,960
beside the workflow.
282
00:09:52,960 --> 00:09:55,520
That doesn't mean the token carries unlimited power.
283
00:09:55,520 --> 00:09:58,280
A token only helps the workload reach the service
284
00:09:58,280 --> 00:10:00,720
it was issued for, and the service still checks
285
00:10:00,720 --> 00:10:02,880
the permissions assigned to that identity.
286
00:10:02,880 --> 00:10:04,640
A temporary pass with a narrow purpose
287
00:10:04,640 --> 00:10:07,480
is very different from handing out one permanent master password.
288
00:10:07,480 --> 00:10:10,120
So the modern flow solves a very practical problem.
289
00:10:10,120 --> 00:10:12,040
Software can access the right service
290
00:10:12,040 --> 00:10:14,240
without borrowing a human account or keeping a password
291
00:10:14,240 --> 00:10:17,920
in its own files, but that same access path can become dangerous
292
00:10:17,920 --> 00:10:19,840
when the identity has too much permission
293
00:10:19,840 --> 00:10:23,440
or when someone steals the way it proves who it is.
294
00:10:23,440 --> 00:10:26,080
Why workload identities need their own security rules?
295
00:10:26,080 --> 00:10:28,360
Now, tokens are cleaner than sharing passwords,
296
00:10:28,360 --> 00:10:31,320
but a workload identity still needs serious protection.
297
00:10:31,320 --> 00:10:33,480
Think of it like a robot that works in your office.
298
00:10:33,480 --> 00:10:36,200
It can't tap a proof on a phone or type a code.
299
00:10:36,200 --> 00:10:38,760
Some workloads run all day long, calling services,
300
00:10:38,760 --> 00:10:41,440
moving files, reading data, and deploying code
301
00:10:41,440 --> 00:10:43,080
while nobody watches the screen.
302
00:10:43,080 --> 00:10:45,480
In some cases, one app has access to more systems
303
00:10:45,480 --> 00:10:47,400
than a single employee ever needs.
304
00:10:47,400 --> 00:10:49,000
That creates a different kind of risk.
305
00:10:49,000 --> 00:10:51,240
You can ask a person to approve an MFA prompt
306
00:10:51,240 --> 00:10:54,000
or use a security key, an app can't do either.
307
00:10:54,000 --> 00:10:56,880
So an attacker doesn't try to trick the app into tapping a proof.
308
00:10:56,880 --> 00:10:58,600
They look for what the app uses instead
309
00:10:58,600 --> 00:11:00,800
that might be a client secret, it might be a certificate,
310
00:11:00,800 --> 00:11:02,760
it could be a stolen token or permissions
311
00:11:02,760 --> 00:11:05,040
that were far too broad from the start.
312
00:11:05,040 --> 00:11:07,080
Picture a developer setting up a new app registration
313
00:11:07,080 --> 00:11:08,680
for a small internal tool.
314
00:11:08,680 --> 00:11:11,680
They create a client secret, paste it into a config file,
315
00:11:11,680 --> 00:11:13,800
and add the same secret to a build pipeline
316
00:11:13,800 --> 00:11:15,600
so the app can deploy automatically.
317
00:11:15,600 --> 00:11:17,840
The tool works and everyone moves on.
318
00:11:17,840 --> 00:11:19,600
Months later, that config file ends up
319
00:11:19,600 --> 00:11:21,920
in a source code repository, or someone copies
320
00:11:21,920 --> 00:11:23,960
the pipeline settings into another project.
321
00:11:23,960 --> 00:11:26,200
Anyone who gets that secret can sign in as the app,
322
00:11:26,200 --> 00:11:30,160
not as themselves, until the secret expires or an admin removes it.
323
00:11:30,160 --> 00:11:31,760
Entrassies the request as the app.
324
00:11:31,760 --> 00:11:33,280
That's why a client secret deserves
325
00:11:33,280 --> 00:11:35,040
the same care as a powerful password,
326
00:11:35,040 --> 00:11:36,920
and why it should be the last choice
327
00:11:36,920 --> 00:11:38,800
when a better sign-in method exists.
328
00:11:38,800 --> 00:11:40,960
For a workload that runs inside Azure,
329
00:11:40,960 --> 00:11:44,000
start with a managed identity when the service supports it.
330
00:11:44,000 --> 00:11:47,200
For code that runs outside Azure like a GitHub actions pipeline,
331
00:11:47,200 --> 00:11:49,520
look at workload identity federation.
332
00:11:49,520 --> 00:11:52,280
That phrase sounds complicated, but the idea is simple.
333
00:11:52,280 --> 00:11:54,400
GitHub can prove which workflow is running,
334
00:11:54,400 --> 00:11:55,960
which repository it came from,
335
00:11:55,960 --> 00:11:57,880
and under what conditions it started.
336
00:11:57,880 --> 00:12:00,120
Entrassed that proof for a defined setup,
337
00:12:00,120 --> 00:12:02,600
then issues a short-lived token to the pipeline.
338
00:12:02,600 --> 00:12:06,800
No long-lived entry secret needs to sit in GitHub waiting to be copied.
339
00:12:06,800 --> 00:12:08,280
If neither managed identity,
340
00:12:08,280 --> 00:12:10,040
no federation works for your app,
341
00:12:10,040 --> 00:12:12,880
a certificate is usually a better choice than a client secret.
342
00:12:12,880 --> 00:12:15,960
Certificates still need safe storage and planned renewal,
343
00:12:15,960 --> 00:12:19,400
but they're harder to casually copy and use than a plain-text secret.
344
00:12:19,400 --> 00:12:22,160
Client secrets still exist because some older apps need them.
345
00:12:22,160 --> 00:12:24,360
Treat them as an exception, not the default.
346
00:12:24,360 --> 00:12:25,760
The next control is permission.
347
00:12:25,760 --> 00:12:28,720
An identity should receive only what its job requires.
348
00:12:28,720 --> 00:12:30,960
If a reporting app needs one SharePoint folder,
349
00:12:30,960 --> 00:12:32,560
don't give it access to every site.
350
00:12:32,560 --> 00:12:34,760
If a workload needs one secret from Key Vault,
351
00:12:34,760 --> 00:12:36,880
don't give it permission to read every secret.
352
00:12:36,880 --> 00:12:39,360
If a pipeline deploys to one Azure resource group,
353
00:12:39,360 --> 00:12:42,120
don't hand it owner access across the whole subscription.
354
00:12:42,120 --> 00:12:43,920
Broad access feels easy during setup,
355
00:12:43,920 --> 00:12:47,320
but it also turns one stolen identity into a much larger incident.
356
00:12:47,320 --> 00:12:49,640
Microsoft Entra can apply conditional access
357
00:12:49,640 --> 00:12:51,120
to workload identities too.
358
00:12:51,120 --> 00:12:53,520
These are rules, Entra checks when it issues a token.
359
00:12:53,520 --> 00:12:55,840
For example, a policy can limit a workload
360
00:12:55,840 --> 00:12:58,440
to expected locations or respond to risk signals.
361
00:12:58,440 --> 00:13:00,200
The app won't get an MFA prompt,
362
00:13:00,200 --> 00:13:02,240
but Entra can still decide whether the conditions
363
00:13:02,240 --> 00:13:04,240
around that request look acceptable.
364
00:13:04,240 --> 00:13:05,560
Logs matter just as much.
365
00:13:05,560 --> 00:13:08,600
Review workload sign-ins, watch for repeated failures,
366
00:13:08,600 --> 00:13:10,600
access from an unexpected location,
367
00:13:10,600 --> 00:13:12,320
sudden activity at odd times,
368
00:13:12,320 --> 00:13:15,480
or an app calling services it normally never touches.
369
00:13:15,480 --> 00:13:17,520
Microsoft Entra ID protection can help surface
370
00:13:17,520 --> 00:13:19,000
risky workload activity,
371
00:13:19,000 --> 00:13:20,880
but a tool can't decide whether an old app
372
00:13:20,880 --> 00:13:22,280
still has a business purpose.
373
00:13:22,280 --> 00:13:23,680
A person needs to own that answer.
374
00:13:23,680 --> 00:13:26,160
Every workload identity needs a named owner.
375
00:13:26,160 --> 00:13:27,800
That owner should know why it exists,
376
00:13:27,800 --> 00:13:29,440
what it can access, how it signs in,
377
00:13:29,440 --> 00:13:31,320
and when somebody will review it again.
378
00:13:31,320 --> 00:13:32,360
When the app disappears,
379
00:13:32,360 --> 00:13:34,760
its identity and permissions should disappear too.
380
00:13:34,760 --> 00:13:37,880
Many companies treat app security as a one time setup task,
381
00:13:37,880 --> 00:13:40,160
create the service principle, grant access,
382
00:13:40,160 --> 00:13:42,480
confirm the app works, and forget about it.
383
00:13:42,480 --> 00:13:44,200
But old projects don't clean themselves up,
384
00:13:44,200 --> 00:13:47,160
an unused service principle can keep permissions for years.
385
00:13:47,160 --> 00:13:49,600
A forgotten certificate can remain valid.
386
00:13:49,600 --> 00:13:51,240
A former team may leave behind automation
387
00:13:51,240 --> 00:13:52,200
that nobody can explain,
388
00:13:52,200 --> 00:13:54,680
yet nobody wants to disable because something might break.
389
00:13:54,680 --> 00:13:56,080
That uncertainty is the risk,
390
00:13:56,080 --> 00:13:58,120
so you don't need to memorize every enter setting.
391
00:13:58,120 --> 00:14:00,080
You need a simple way to choose the right pattern
392
00:14:00,080 --> 00:14:03,200
then check access before a workload goes live.
393
00:14:03,200 --> 00:14:05,400
Picking the right pattern without overthinking it,
394
00:14:05,400 --> 00:14:07,960
you don't need to turn this into a big architecture project.
395
00:14:07,960 --> 00:14:10,640
Start with one question, where does the workload run?
396
00:14:10,640 --> 00:14:12,120
If it runs inside Azure,
397
00:14:12,120 --> 00:14:15,040
on a virtual machine app service, function, or logic app,
398
00:14:15,040 --> 00:14:17,160
start by checking for a managed identity.
399
00:14:17,160 --> 00:14:18,840
Turn it on, then give that identity
400
00:14:18,840 --> 00:14:21,840
the smallest role or permission the workload needs.
401
00:14:21,840 --> 00:14:24,760
A function that only reads blobs from one storage account
402
00:14:24,760 --> 00:14:26,800
should get access to that storage account,
403
00:14:26,800 --> 00:14:29,680
not every storage account in the subscription.
404
00:14:29,680 --> 00:14:32,240
A logic app that needs one key vault secret
405
00:14:32,240 --> 00:14:34,840
should receive access to that secret, not the whole vault.
406
00:14:34,840 --> 00:14:36,520
The location of the code tells you a lot.
407
00:14:36,520 --> 00:14:38,160
If the code runs outside Azure,
408
00:14:38,160 --> 00:14:40,800
perhaps in GitHub Actions or another Cloud Platform,
409
00:14:40,800 --> 00:14:42,800
look for workload identity federation.
410
00:14:42,800 --> 00:14:44,520
The outside platform proves what it is
411
00:14:44,520 --> 00:14:46,040
using its own trusted token.
412
00:14:46,040 --> 00:14:47,080
Entra checks that trust,
413
00:14:47,080 --> 00:14:49,400
then gives the workload a short-lived enter token.
414
00:14:49,400 --> 00:14:50,760
That lets a pipeline deploy
415
00:14:50,760 --> 00:14:54,200
without keeping a long-lived secret in the pipeline settings.
416
00:14:54,200 --> 00:14:56,120
The third question applies to custom apps.
417
00:14:56,120 --> 00:14:58,120
Does the app need to sign in as itself,
418
00:14:58,120 --> 00:15:00,160
work across more than one organization,
419
00:15:00,160 --> 00:15:03,000
or request app permissions for Microsoft 365,
420
00:15:03,000 --> 00:15:04,840
or another Entra protected service?
421
00:15:04,840 --> 00:15:07,240
If yes, you'll usually use an application registration
422
00:15:07,240 --> 00:15:08,560
and a service principal.
423
00:15:08,560 --> 00:15:10,480
The application registration describes the app.
424
00:15:10,480 --> 00:15:13,600
The service principal receives access inside each organization,
425
00:15:13,600 --> 00:15:14,720
where the app runs.
426
00:15:14,720 --> 00:15:16,200
When that app needs a credential,
427
00:15:16,200 --> 00:15:19,200
choose a certificate over a client secret where you can.
428
00:15:19,200 --> 00:15:21,360
A certificate still needs careful handling,
429
00:15:21,360 --> 00:15:22,680
but it gives you a stronger option
430
00:15:22,680 --> 00:15:25,800
than a plain text secret copied between people and systems.
431
00:15:25,800 --> 00:15:27,400
Think about a simple file scenario.
432
00:15:27,400 --> 00:15:30,080
Your personal work files usually begin in one drive.
433
00:15:30,080 --> 00:15:31,720
Team files usually live in SharePoint,
434
00:15:31,720 --> 00:15:33,240
that tells you where the files belong,
435
00:15:33,240 --> 00:15:35,760
but it doesn't give an app access to either place.
436
00:15:35,760 --> 00:15:38,080
The app still needs its own Entra identity.
437
00:15:38,080 --> 00:15:39,800
Then you decide whether it can read a folder,
438
00:15:39,800 --> 00:15:41,680
upload a file, or do nothing at all.
439
00:15:41,680 --> 00:15:44,520
File location and app access are separate decisions.
440
00:15:44,520 --> 00:15:46,000
Before any workload goes live,
441
00:15:46,000 --> 00:15:48,360
ask five plain questions, who owns this identity,
442
00:15:48,360 --> 00:15:50,040
what can it access, how does it sign in,
443
00:15:50,040 --> 00:15:51,560
where will someone review its logs,
444
00:15:51,560 --> 00:15:53,160
and when will its access be removed?
445
00:15:53,160 --> 00:15:54,880
Those questions work for a brand new app,
446
00:15:54,880 --> 00:15:57,360
but they also expose risk in apps already sitting
447
00:15:57,360 --> 00:15:58,280
in your directory.
448
00:15:58,280 --> 00:16:00,160
An old service principle with no owner,
449
00:16:00,160 --> 00:16:01,920
a client secret nobody remembers,
450
00:16:01,920 --> 00:16:04,200
and broad permissions nobody can explain should not stay
451
00:16:04,200 --> 00:16:05,960
invisible just because the app still exists.
452
00:16:05,960 --> 00:16:08,240
You don't need an admin deep dive to begin,
453
00:16:08,240 --> 00:16:09,520
you need an inventory,
454
00:16:09,520 --> 00:16:12,600
and a willingness to ask what each workload is doing.
455
00:16:12,600 --> 00:16:15,320
So how do you do a workload identity check?
456
00:16:15,320 --> 00:16:17,160
Start by listing all your applications,
457
00:16:17,160 --> 00:16:19,600
service principles, and managed identities,
458
00:16:19,600 --> 00:16:21,560
then attach a real owner to every single one.
459
00:16:21,560 --> 00:16:22,480
That's step one.
460
00:16:22,480 --> 00:16:24,720
Next, hunt for client secrets hiding in code,
461
00:16:24,720 --> 00:16:26,560
config files, and build pipelines.
462
00:16:26,560 --> 00:16:28,880
If an Azure workload can use a managed identity,
463
00:16:28,880 --> 00:16:31,560
move it in that direction, then review permissions,
464
00:16:31,560 --> 00:16:33,720
remove any identities nobody uses,
465
00:16:33,720 --> 00:16:35,640
and watch the sign in logs for activity
466
00:16:35,640 --> 00:16:36,880
that doesn't fit the job.
467
00:16:36,880 --> 00:16:39,880
An unattended app can still open doors across your company,
468
00:16:39,880 --> 00:16:41,120
treated with the same care,
469
00:16:41,120 --> 00:16:42,840
you'd give a highly privileged account.
