The Domain Somebody Proved They Own
Microsoft's directory does not send a field saying an address was verified, because it does not need one — a work address exists only on a domain the organisation proved it owns. Except for guests, whose addresses are minted from somewhere else entirely.
The rule for accepting a sign-on identity is to refuse any address the provider has not verified. Straightforward, until a provider that clearly does verify addresses turns out not to send the field. Applying the rule literally would refuse every Microsoft sign-in forever; ignoring it would accept whatever arrives. The answer is neither, and working out what it is means understanding what a work account actually is.
Why the field is not there
The identity is read from the directory's own profile interface — the endpoint that answers who the signed-in user is. That payload describes a person in an organisation: their name, their address, their identifier.
The claims that state whether an address was verified live in a different artefact — the token issued during sign-in — and are not part of a profile.
So a check that reads a profile for a verification claim finds nothing. Not false. Absent. And absent is indistinguishable from unverified to a test that only knows how to look for a claim, which is why the honest reading of the rule would reject every legitimate sign-in from an entire provider.
A rule that refuses everybody is not a strict rule. It is a broken one, and the pressure to remove it entirely is exactly what makes this dangerous.
What a work address already proves
Here is the part that resolves it, and it is a genuinely good piece of reasoning about how directories work.
An organisation cannot simply declare that its accounts live on a domain. Before the directory will issue accounts there, the organisation has to demonstrate control of that domain by publishing a record in its public naming records — something only somebody who administers the domain can do.
And a person cannot choose their own address within it. It is assigned by whoever administers the directory.
-
The organisation proved the domain
By publishing a record only its administrators could publish. That is a stronger proof than a confirmation email.
-
An administrator assigned the address
Not the user. There is no field where somebody types their own work address.
-
So the address is attested by the directory
Its existence is the proof, which is why no separate claim is needed to say so.
-
And the directory is the organisation
Which is what makes it more meaningful than a personal account confirming an address.
So the presence of a well-formed work address, on a directory account, is proof of the same fact the missing claim would have stated. It is not a workaround; it is a different route to the same assurance, and arguably a stronger one.
And then the exception
This is where the reasoning would fall apart if it stopped, and the exception is the reason the check is three conditions rather than one.
Directories can hold guests — people from outside invited into an organisation, keeping their own identity. Consultants, auditors, a supplier's project manager.
A guest gets an address in the host directory, minted from their external one. The host directory never verified that external address. It took an invitation to it and built a name out of it, which is a completely different thing.
The chain of reasoning breaks exactly there: the domain was proved by the host, but the address was not attested by anybody — the visible portion of it is a mangled copy of something the host organisation has no relationship with.
Guest addresses carry a distinguishing marker in their structure, and the check refuses them. Three conditions: present, well-formed, and not a guest.
Why this is the hard kind of security work
Nothing in this is cryptographic. There is no signature to verify, no timing to constant-ise, no library to reach for. It is a chain of reasoning about a provider's identity model, ending in one condition on a string.
And it has the property that makes this category expensive: every step of the reasoning has to be right, and the code that results from it looks trivial.
A future reader sees a check for a substring in an address. Without the reasoning written beside it, it looks arbitrary — the sort of thing somebody adds during a debugging session and forgets to remove. Removing it produces no failure, no error and no test result. It produces a directory where an invited outsider can sign in as though they were staff.
Which is why the reasoning is recorded next to the code rather than in a commit message somebody would have to go looking for.
One smaller thing in the same function
Where a provider does send a verification claim, reading it is less simple than it should be.
The value can arrive as a boolean, as a number, or as text — because payloads travel through encodings that flatten types, and different providers made different choices about how to express a yes.
A test written for one of those forms silently fails on the others. Comparing to a boolean means a text value is not equal to it, and the claim reads as false — a legitimate identity refused, with the check appearing to work.
So the reading accepts the several forms a yes actually takes, and treats everything else as no. It is unglamorous, and it is the difference between a check that works across providers and one that works against the payload it was written for.
What is in place, layer by layer
How a directory identity is trusted
Verification defined per provider
Each provider's own way of proving an address is read, rather than one shared test that would refuse an entire provider or accept unproven addresses from others.
A directory address accepted as proof
A work address exists only on a domain the organisation proved it controls, and is assigned rather than chosen — which is the fact a verification claim would have stated.
Guest accounts refused
An invited outsider's address is minted from an external one the host directory never verified, and is rejected by the marker its structure carries.
Three conditions, not one
The address must be present, well-formed, and not a guest — because each of the three covers a different way the reasoning fails.
The reasoning recorded beside the code
A substring check on an address looks arbitrary without it, and removing it produces no error, no failure and no test result.
Claims read across their several forms
A yes can arrive as a boolean, a number or text, and a test written for one form silently refuses legitimate identities from providers using another.
Anything unrecognised treated as no
A value that does not clearly mean yes is not accepted, so a new representation fails closed rather than open.
Address format checked first
A malformed value never reaches a comparison against an account, whichever provider it came from.
None of this is cryptographic. It is a chain of reasoning about a provider's identity model that ends in one condition on a string — which is why the reasoning has to live beside the condition.
Three positions held on purpose
- A missing claim is not treated as a failure of the rule. Where a provider proves an address by a different mechanism, that mechanism is understood and used — because a rule that refuses everybody gets removed rather than fixed.
- Guests are refused explicitly. The reasoning that makes a work address trustworthy does not extend to an address minted from an invitation, and the distinction is a single condition that produces no symptom when it is wrong.
- The reasoning is written where the code is. A substring check with no explanation is indistinguishable from debugging left behind, and deleting it produces no error anywhere.
Five questions about directory sign-on
How do you know a Microsoft address is verified?
A good answer sounds like
A specific mechanism.
What ours actually is
A directory address exists only on a domain the organisation proved it owns and is assigned rather than chosen.
What about guest accounts?
A good answer sounds like
Refused.
What ours actually is
A guest address is minted from an external one nobody verified, and is rejected by the marker it carries.
What if the verification claim is missing?
A good answer sounds like
Not simply accepted.
What ours actually is
Handled by understanding how that provider proves it, rather than by skipping the check.
What if a claim arrives as text rather than a boolean?
A good answer sounds like
Still read correctly.
What ours actually is
The several forms a yes actually takes are accepted; anything else is treated as no.
Is this documented anywhere?
A good answer sounds like
Beside the code.
What ours actually is
The reasoning sits with the condition, because removing the condition produces no failure of any kind.
Our take
The security work that is genuinely hard is almost never the cryptography. It is establishing what a third party's data actually means — which requires reading their identity model rather than their API reference, and produces code that looks like nothing. A substring check. A missing field handled a particular way. Three conditions where one would appear to do. Every one of those is a conclusion, and the conclusion is the valuable part; the code is a footnote. If you write one, write down why, because the next person to read it will have every reason to think it is noise and no way at all to find out otherwise.
Sign in with the directory your organisation already runs
Work accounts, assigned by your administrators, on a domain you proved you own — with guests deliberately not treated as staff.
Talk through sign-in securityFrequently asked questions
Can guests in our Entra directory sign in?
Not through this route. A guest account's address is minted from an external one that your directory never verified — it took an invitation to that address and built a name out of it. The reasoning that makes a staff address trustworthy does not extend to that, so guest identities are refused.
Why is a Microsoft work address accepted without a verification claim?
Because the address existing is the proof. Your organisation cannot issue accounts on a domain until it has demonstrated control of that domain by publishing a record only its administrators could publish, and a person cannot choose their own address within it. That is the fact a verification claim would have stated.
Is that weaker than checking a claim?
Arguably stronger. A verification claim on a personal account usually means somebody clicked a link in an email. A directory address means an organisation proved ownership of a domain and an administrator assigned the account.
What happens if Microsoft starts sending a verification claim?
It would be read like any other, because the claim check runs first and the directory reasoning is the path taken when no claim is present. The two are not alternatives — the second is what happens when the first finds nothing to read.
Do you handle claims that arrive in unusual formats?
Yes. A yes can arrive as a boolean, a number or a piece of text depending on the provider and the encoding it travelled through, and a check written for one form silently refuses legitimate identities using another. Anything that does not clearly mean yes is treated as no.
