►
Description
Authentication to applications aimed at customers and partners requires zero trust levels of security, while demanding UX and controls flexibility to fit diverse customer audiences. In this session we review how to assess the risk status of your applications using Identity Protection and how to control access with smart conditional policies leveraging real time risk assessments.
Speakers: Jose Rojas, Vikas Deora
For more information, https://developer.microsoft.com/en-us/identity/
Stay connected
Twitter https://twitter.com/microsoft365dev
YouTube https://aka.ms/M365DevYouTube
Blogs https://aka.ms/M365DevBlog
A
I'm
here
with
my
my
partner
in
crime
here,
vikas
dora.
Let
me
do
a
little
introduction.
Let's
introduce
ourselves
briefly
to
the
to
the
audience,
jose
rojas,
I'm
a
pm
in
the
identity
division.
I
am
currently
part
of
the
identity
platform
team
and
for
quite
some
time
I
have
been
working
in
the
platform
for
usher,
active
directory
b2c,
and
it's
through
that
work
that
I
interact
very
very
frequently
with
vikas
and
he'll
introduce
himself
from
the
security
team.
A
A
B
Thanks
jose
because
dearer
I'm
part
of
the
product
group
for
conditional
access,
my
job
is
to
make
sure
that
all
identities
are
protected,
be
your
employees,
your
partners,
and
now
your
customers,
your
consumer,
apps.
So
that's
my
role
in
microsoft.
To
make
sure
we
take
protecting
identity
seriously
and
doing
our
best
to
get
the
features
out
to
you.
So
you
can
secure
all
identities
great.
So.
A
Okay,
let's
jump
right
in
we're
gonna
try
to
address
questions
that
you
put
in
the
chat
as
we
go
along.
If
not,
we
will.
I
I
personally
follow
with
with
each
one
of
your
your
your
questions
directly
if
we're
unable
to
address
them
during
the
call,
let's
jump
right
in
we'd
like
to
first
talk
about
the
the
landscape
of
protecting
your
application
and
consumer's
identities.
We'll
get
briefly
through
this
because
we
want
to
get
to
the
demo
stuff.
A
So
a
couple
things.
First
of
all,
we
think
that
it
is
absolutely
critical
to
protect
yourself
against
attacks.
These
are
proactive
attacks.
We
encounter
this
all
the
time
and
you
gain
the
benefit
of
us
having
been
receiving
at
the
receiving
end
of
this
for
microsoft
as
well,
for
like
really
hundreds
of
thousands
of
customers
customer
tenants
more
recently,
password
spray
has
become
particularly
habitual
and
the
team
has
done
a
ton
of
effort
to
improve
our
resiliency.
A
Our
ability
to
react
to
that
and
we'll
talk
about
that
a
little
bit
briefly
and
then,
when
it
comes
to
ddos
on
microsoft
of
microsoft
itself,
we're
able
to
we've
been
able
to
for
quite
some
time
be
able
to
protect
ourselves
from
it,
and
we
hope
that
through
our
other
astro
capabilities
are
not
the
ones
we're
discussing
this
call.
We
can
also
your
applications,
then
there's
the
need
to
identify
and
mitigate
risk.
A
This
helps
you,
but
we
know
we're
only
part
of
a
bigger
answer,
which
is
where
all
the
risks
that
are
applying
to
your
applications.
We
hope
this
at
least
triggers
those
conversations
and
quick
and
quickly
on
the
side
of
mitigating
risk.
We'll
also
talk
about
that
today,
because
it's
very
much
about
what
to
do
when
this
happens
and
what
policies
can
you
apply
that
are
both
customer
friendly
and
effective
against
the
attacks
in
your
organizations?
A
A
Accessing
your
user's
computer,
sometimes
some
of
that
is
necessary
for
some
specific,
privileged
actions,
but
you
can
combine
an
mfa
layer
together
with
a
mitigation
layer
and
that
we
will
show
you
shortly
and
lastly,
we
and
you
are
with
azure
active
directory.
If
not,
you
should,
because
the
ability
to
give
you
high
availability
and
being
globally
available
from
customers
worldwide,
especially
these
times
where
I'm
sure
many
of
you
who
have
online
identities
or
online
commerce
are
receiving
visits
from
all
over
the
world.
A
A
A
It's
something
that's
much
more
common
in
corporate
than
consumer,
but
we
also
would
would
encourage
you
to
do
that
in
this
azure
active
directory
that
can
help
you
achieve
that
right,
all
the
way
down
to
detect
and
sign
ins
and
any
suspicious
activity
into
any
from
any
entry
point
to
organization,
so
hearts
corporation.
The
article
will
tell
you
more
about
how
they've
achieved
that,
because.
B
For
british
petroleum,
they
had
a
interesting
scenario
where
they
really
want
to
protect
security
for
all
their
users
and
80
000
of
them
with
mfa,
but
they
they
wanted
to
do
it
in
the
most
seamless
fashion,
so
they're
not
interrupting
the
users
with
mfa
constantly
always
on
so
one
of
the
things
they
did
was
they
focused
highly
on
the
risk-based
policies
and
they
rolled
out
successfully
mfa
based
on
risk.
So,
instead
of
triggering
mfa
all
the
time,
those
mfa
were
only
triggered
when
the
when
the
risk
signals
were
off
certain
certain
level.
A
Great
thank
you
because
so
a
bit
of
a
reminder
right-
and
this
is
something
that
many
of
you
are
probably
aware
of
in
you
in
this
call,
but
when
you
communicate
to
other
parts
of
your
organization,
something
to
keep
in
mind
right.
So
we
were.
We
were
coming
from
a
world
where
you
know
every
user
was
an
employee
and
now
we're
on
our
way
to
a
world
that
every
user-
and
it's
particularly
interesting-
it's
not
just
a
employee
but
also
partners
and
customers
and
bots,
of
course
right.
A
So
the
idea
that
we
need
you,
we
know
you're,
faced
with
the
challenge
of
expanding
your
login
options
and
also
you
have
to
be
ever
more
careful
with
how
strict
you
are
or
what
you.
What
do
you
do
to
mitigate
your
risk,
and
this
is
a
little
bit
of
what
pcc
provides
the
control
that
we're
going
to
share
control,
we're
going
to
share
with
you,
which
is
to
apply
the
security
but
to
apply
it
when
it's
needed
right
rather
than
a
blanket.
You
know
everybody
must
mfa.
We
now
enter
territory.
A
We
know
that
applications
have
to
have
to
work
from
everywhere
and
not
only
in
your
applications
on
the
consumer
consumer
side,
but
when
a
user
logs
into
your
application
and
then
has
to
access
other
applications
within
yours,
they
can
come
from
anywhere
right
and
that's
where
the
the
the
third
point
about
composite
apps
right,
the
apps
are
based
on
reaching
a
new
authentication
across
multiple
domain
boundaries,
and
we
know
you
have
you
have
to
figure
this
out
and
work
this.
This
is
something
we
think
about
in
the
idea.
A
All
the
time
and
lastly,
especially
in
the
consumer
case,
has
always
been
the
case
that
customers
are
going
to
come
from
everywhere
right.
Not
only
can
they
come
from
everywhere,
but
after
they
as
they
use
your
service,
you
want
to
redirect
them
to
a
partner
service
and
direct
them
anywhere
else.
So
we
know
you
live
in
this
world
where
you
really
you.
Can
you
there's
very
few
things?
You
can
trust,
so
the
establishment
of
every
session
requires
you
to
evaluate
the
risk
of
each
one
of
those
sessions
right.
A
So
in
this
context,
we
have
three
things
that
we'd
like
to
advise
you
to
do
and
do
all
the
time
right
so
number
one
is
the
need
to
explicitly
verify
all
identities
right
with
some
some
form
of
mfa.
Now
you
don't
have
to
do
this
all
the
time,
but
certainly
anytime,
that
a
user
comes
in
for
the
first
time.
The
first
time
you
see
a
particular
browser.
A
This
is
something
you
ought
to
do
and
especially
when
users
go
to
access
some
of
your
privileged
sections,
which
could
be
areas
like
changing
credit
card
number
accessing
addresses
accessing
sensitive
information
where
you
want
to
explicitly
verify
the
identities.
We
have
the
case
of
a
customer,
a
major
retailer
in
the
united
states
that
implemented
this
in
a
way,
that's
only
under
certain
portions
of
their
on
their
commerce.
A
Ecommerce
website
is
the
mfa
required
and,
as
we'll
show
you
that
can
be
done
in
a
neutral
number
of
ways,
so
it
doesn't
always
have
to
be
at
the
first
entry
point,
but
it
does
require
those
of
you
to
develop
apps
to
be
a
little
bit.
Thought
build
a
bit
more
thoughtful
as
to
which
portions
of
the
experience
really
require
mfa,
and
this
is
how
you
do
this
without
damaging
the
consumer.
Experience
me
to
cs's
stance
today
supports
phone-based
mfa
and
that's
tech,
stuff
or
voice.
A
We,
we
do
support
email,
verification
in
lieu
of
mfa
right.
We
know
it's
not
as
strong
as
a
you
know.
You
truly
using
a
different
device,
but
in
consumer
situations,
it's
quite
effective
in
in
doing
an
additional
check
on
on
the
user
and
getting
the
benefit
of
the
security.
The
additional
security
of
email
providers
like
like
outlook.com,
live.com
or
really
google
gmail
right
and
then
also
b2c,
allows
the
ability
to
use
third-party
services
right.
A
This
can
be
done
in
advanced
configuration,
but
third-party
services,
like
twilio,
who
also
do
mfa
or
who
have
authy
as
an
authenticator
application,
is
also
possible.
We
are
often
asked
about:
when
will
we
have
authenticator
support
in
b2c,
and
this
has
been
and
something
that
we
we
continue
to
have
high
on
our
list.
We
just
have
not
quite
gotten
to
it,
but
we'll
continue
to
carry
over
to
the
next
calendar
year
and
we
hope
to
be
able
to
achieve
it
right
now.
A
If
there's
any
doubt
in
anybody's
mind
right
the
simple
step
of
adding
an
mfa,
especially
when
you
need
it,
it's
incredibly
incredibly
successful
in
preventing
and
stopping
identity
attacks
right,
we
still
see
organizations
who
do
not
use
mfa
and
the
difference
is
dramatic
right.
So,
like
you,
don't
have
to
have
something
extremely
advanced,
just
that
additional
obstacle
keeps
a
lot
of
the
bad
guys
out.
A
B
When
you're
enabling
mfa,
you
have
multiple
choices.
If
you
use
conditional
access
and
we
hope
you
use
conditional
access
for
enabling
mfa,
you
get
options
to
use
signals
to
to
decide
what
triggers
mfa
and
one
of
the
things
which
is,
which
is
very
important.
Is
you
think
about
this
quite
hard
when
you,
when
you
build
your
security
posture,
it's
very
easy
to
just
enable
mfa
all
the
time,
all
the
apps
all
the
users,
but
it
also
means
that
there
is
a
kind
of
a
balance
between
security
and
productivity.
B
What
we
want
to
do
is
we
want
you
to
be
secure
and
productive,
so
we
want
you
to
create
a
security
posture
which
is
not
hindering
your
customers.
You
know
you
people
who
are
going
to
use
your
consumer
apps,
so
so
one
of
the
best
practices
is
to
think
about
what
those
signals
are,
and
one
of
the
key
signals
which
you
can
potentially
use
are
risk
pins.
B
What
risk-based
signals
does
for
you
is,
you
can
say
you
know
if
the
sign-in
risk
is
high,
then
require
mfa,
or
if
the
user
risk
is
high,
require
password
change.
When
you
do
something
like
signing,
risk
is
high
required
mfa.
The
mfa
is
triggered
only
when
you're,
when
you
know
that
you
know
there
is
a.
There
is
a
there's,
an
issue
there's
a
problem:
it's
not
happening
all
the
time
when
you
know
it's
from
the
patterns
from
the
signal
you
know
I.
It
looks
like
this
right
user.
B
I
can't
see
the
user
has
just
traveled
from
new
york
to
london
in
in
five
minutes
or
with
the
user
risk
you
can
see.
You
know
I
can
see
the
passwords
being
advertised
in
the
public
internet.
So
I
think
there
is.
There
is
an
issue.
There
is
a
compromise
of
the
password
how
and
when
the
bad
guy
use
they
come
in,
they
either
trigger
the
sign
risk
or
the
user
risk.
B
So
you
have
captured
the
signals
which
are
coming
from
the
bad
guys
and
preventing
the
bad
guys
going
into
the
apps,
while
the
good
guys
goes
through
with
the
with
the
right
mfa
prompt
into
the
apps.
So
the
the
idea
with
the
conditions
and
controls
with
conditional
access,
is
to
make
sure
that
you
have
a
seamless
experience
for
your
human
apps,
making
sure
that
your
users
are
getting
to
the
apps
in
a
in
a
non-fictional
way
and
have
thinking
about
this
identity
protection.
B
Real-Time
risk
to
trigger
your
mfa
and
allow
policies
are
are
going
to
be
key
to
your
success
for
for
achieving
a
huge
rollout
and
it
will
keep
your
keep
the
bad
guys
off
from
licensing
perspective.
It
is
a
premium
offering
real-time
risk.
Is
it
comes
under
p2
licensing,
while
the
other
factors
like
users
locations,
they
come
under
p1
and
the
the
benefit
you
get
with
that
is
you
get
you
know
kind
of
monitoring
on
the
wrist
signals
you
get
detections
of
the
risk
signals.
B
So
there's
there's
a
lot
of
benefit,
there's
a
lot
of
goodness
of
of
capturing
the
signals,
knowing
these
signals
and
kind
of
maintaining
your
security
posture
around
these
around
the
signals
jose
is
going
to
discuss
about
how
do
we
actually
measure
some
of
these
risks,
but
once
you
get
the
measurements
with
the
conditional
access
policies,
you
can
trigger
the
right
controls,
which
are
required
mfa
only
when
the
signal
is
high-
and
that's
that's
that
gives
you
an
amazing
seamless
experience
for
your
apps.
So
that's
that's
the
slide.
B
Just
think
of
these
conditions,
under
which
your
controls
needs
to
be
triggered.
So
having
these
conditions
and
controls
through
conditional
access
policies
allows
you
to
manage
your
whole
security
posture
for
all
your
consumer
apps
and
not
just
app
by
app
you
can
you
can
build
all
your
apps
and
just
apply
a
conditional
access
policy
which
will
take
care
of
your
security
posture
for
all
your
apps,
all
your
consumer
apps
on
what
they
need
to
do
when
any
of
your
consumers
access
your
apps.
B
So
that
was
kind
of
like
that
think
about
your
conditions,
think
about
the
controls
and
think
about
real-time
risk
when
you're,
when
you're,
enabling
conditional
access
policies
are
they
if
you
go
for
the
next
one
yeah,
so
the
when
you're,
enabling
these
policies,
especially
conditional
access
policies,
you
have
a
huge
plethora
of
options,
you
can
use
the
ui
or
you
can
use
the
apis,
we'll
recommend
using
the
apis,
because
you
get
the
full
automations
you
can
as
part
of
your
app
dev
sec.
Ops,
you
can
you
can
build
your
apps.
B
You
can
make
sure
that
they're
light
they
light
up
with
the
right
security
posture
from
the
day,
one
as
they
go,
live
so
go
ahead
and
use
initial
access,
use,
risk-based
policies
and
use
apis
to
configure
your
policies
to
manage
your
devsec
ops
journey.
So
that's
the
that's
this
one
jose
off
to
you.
Yep.
A
A
These
are
now
available
to
you,
via
the
detection
of
signing
risk,
that's
real
time
and
the
detection
of
user
risk,
which
is
an
offline
assessment
of
whether
an
account
is
currently
compromised
in
any
way,
and
one
incredible
reason
why
microsoft
can
do
this
so
well
is
because
we
do
it
consistently
across
a
gigantic
world
of
different
applications
and
services.
Right
when
you
think
about
a
when
you
think
about
the
1.2
billion
device
scanned
each
month
when
you
think
about
our
security
being
in
90
of
enterprise
and
enterprises.
A
You
know
bot
net
networks,
rail,
identify
if
networks
that
come
up
and
come
down
at
regular
intervals,
trying
to
hide
themselves
and
we're
able
to
communicate
whatever
is
learned
across
the
network
and
in
to
benefit
your
tenants
now,
even
beyond
that
as
crime
specific
crimes
are
analyzed,
there's
feedback
back
into
the
system
to
identify
patterns
that
ought
to
be
detected
going
forward.
So
it's
extremely
robust
system
and
area
microsoft
continues
to
invest
in
in
a
big
way.
So
really
today
is
about
how
do
you
get
to
leverage
this
into
your
own
world?
A
Now
we
wanted
to
highlight
one
specific
signal
that
the
team
had
to
do
a
ton
of
focus
on
which
is
password
spray
right.
It's
really
amazing
number
one
number
one
first
way
to
get
password,
obviously
is-
is
to
get
it
from
an
end
user
right,
but
beyond
that
right
and
through
phishing.
But
beyond
that,
I
wanted
to
just
share
some
numbers
as
to
why
it's
become
such
a
concern
right.
A
So
we
have
as
many
as
nine
million
high-risk
enterprise
hunting
attempts
flagged
two
million
compromised
accounts
detected,
and
by
this
we
mean
accounts
for
which
we
actually
could
tell
through
through
information
out
of
the
dark
web
and
through
to
the
the
analysis
and
actually
through
what
happens
after
right.
They
need
their
work
compromised
and
we're
able
to
detect
them,
identify
and
flag
those
users
as
high
risk
and,
in
many
cases,
prevent
the
access.
A
A
We
will
be
adding
signals
that
we
don't
yet
have
to
say-
and
I
want
to
point
this
out,
because
even
though
we
do
have
password
spray
protection,
we
do
not
have
the
the
ability
to
detect
the
pond
type
situation
where
a
microsoft
can
do
this
on
the
enterprise
side.
But
here's
an
error,
we
don't
quite
have
parity.
Yet
on
the
enterprises,
we
can
detect
application
users
and
passwords
that
have
been
out
in
the
wild
if
you
will
or
available
uncompromised
pond,
if
you
will,
but
on
the
consumer
side,
we
don't
yet
have
this
capability.
A
A
Now
when
it
comes
to
signing
risk
types,
we
prioritize
this
because
we
do
have
the
situation
that
there's
so
much
more,
there's
not
as
much
history
for
user
risk
on
the
b2c
side,
because
users
infrequently
use
drop
your
applications,
but
on
the
signing
risk
tab,
which
is
all
about
the
creating
a
new,
the
starting
of
a
new
session.
We
do
have
an
amazing
amount
of
capability
and
I'm
just
going
to
quickly
mention
a
couple
highlights
here
and
because
please
feel
free
to
jump
in
as
well
right.
A
So
a
typical
travel,
which
is,
as
it
sounds,
right
a
user
who
performed
a
series
of
attempts,
a
second
signing
from
a
place
that
could
not
possibly
be
be
reached.
Unless
you
know
something
special
is
used
like
a
vpn
within
a
period
of
time
right
that
travel
would
not
have
been
possible
anonymous
ip
right,
where
we
know
when
an
ipad
was
associated
with
torn
networks
or
vpns
and
were
able
to
flag
this.
I
want
to.
A
I
want
to
address
a
question
that
was
said
earlier
that
the
fact
that
it
is
detected
does
not
mean
that
it
will
be
rejected
right.
It's
it's
both.
It's
merely
a
detection
that
points
to
a
total,
an
overall
score
that
could
then
lead
to
a
potential
flagging
of
the
user,
sign
invoice
being
high,
medium
or
low.
So
any
single
thing
does
not
necessarily
tip
the
user
over
number.
One
and
number
two
is
still
up
to
you
to
decide
what
to
do
with
it.
Right.
A
Don't
think
that
this
report
automatically
means
the
user
would
be
affected,
malware
linked
ip
addresses
right.
This
is
all
about
button
ip
sources,
and
I
just
want
to
highlight
passwords,
as
I
mentioned
earlier
right,
which
is
a
quite
sophisticated
method
of
attack,
but
the
team
has
made
a
lot
of
progress
in
identifying
that
that
signal.
Because
would
you
highlight
any
others
here
that
you
want
to
bring
up
or
any
experiences.
B
No,
I
think
I
wanted
to
just
add
to
what
you
said
jose
is
that
the
signals
are
collected
over
a
period
of
time.
So
you
have,
you
know,
for
it's
not
just
a
single
event.
There
are
cases
where
there
are
single
events,
but
for
things
like
user
risk,
it's
a
collection
of
events
which
are
slowly
increasing
your
user
risk
and
those
are
adding
up
to
triggering
certain
things
and
generally,
if
you're,
a
good
guy
like
if
you're
trying
to
get
the
things
done,
you
would
see
your
you
are.
You
can
pass
through
the
controls.
B
So
if
it's
user
risk
is
very
high,
you
know
it's.
It
means
that
your
password
is
compromised.
You
change
your
password,
your
imitated
user
risk,
so
the
remediation
happens,
and
then
you
go
back
to
your
zero
user
risk,
so
your
user
risk
goes
back
as
soon
as
you
have
remediated,
so
your
good
guys
are
still
going
in
and
accessing
the
service
after
the
remediation.
So
it
doesn't
block
the
good
guys.
It
keeps
the
bad
guys
out.
A
I
wanted
to
address
the
question
here
about
a
typical
travel
question
was
whether
hey,
if
a
user
habitually
locks
in
from
poland
and
denmark,
because
of
a
vpn
or
just
a
habitual
pipeline
between
the
two
locations,
so
that
over
time
does
not
become
a
typical
right.
A
user
could
have
more
than
one
typical
location,
and
the
system
can
learn
that
right.
It's
not
by
virtue
of
a
single,
a
typical
travel
situation
that
the
user
can
become
immediately
high
risk.
It
can
become
medium
risk.
A
However,
I
would
say
that,
and
in
fact,
when
I'll
show
you
the
report,
you
will
see
a
medium
risk
user
due
to
a
typical
travel
right,
so
it
becomes
more
of
a
flag
which
can
be
confirmed.
If
then,
something
else
happens
that
might
together
tip
deciding
to
be
a
risk,
a
high
signing
risk.
So
hopefully
that
gives
you
a
bit
of
a
feeling
that
you
don't
have
to
completely
worry
about
that.
A
Now,
let's
walk
through
a
quick
example
and
then
a
and
to
make
sure
we
land
the
concepts
here
so
identity
protection.
Overall,
it's
the
combination
of
detecting
the
risk
and
doing
something
about
it
right,
so
we
begin
with
a
any
normal
signing.
This
could
be
done,
though
log
it
into
your
e-commerce
application
immediately.
The
real-time
detections
are
applied
and
a
score
is
attributed
to
that
particular
login.
A
B
A
Let
me
just
go
back
to
the
earlier
ecommerce
example:
the
application,
the
web
application
that
this
particular
e-commerce
company
used
between
the
e-commerce
portion
of
the
site
and
the
financial
portion
of
the
site
actually
reflected
as
two
different
client
types
and
actually
trigger
different
policies.
So
that's
a
way
to
do
that.
Number
one
number
two.
A
What
I'm
going
to
get
to
is
that
the
signals
that
come
out
of
a
ca
policy
can
be
communicated
back
to
your
application,
not
specifically
the
risk
level,
but
the
mitigation
can
be
communicated
back
to
your
application,
so
your
application
can
decide
what
to
do
about
it.
In
this
particular
case,
the
decision
is
to
require
an
affair
to
continue.
If
it's
passed
we're
good,
if
it's
not
passed
right,
then
this
lets
us
know
that
a
risk
event
might
have
happened
and
was
prevented
right
might
have.
A
Indeed,
this
user
was
compromised
and
it
kind
of
feeds
back
into
the
system
get
users
risk.
History
is
also
useful
when
you
have
customer
support
type
situations
that
a
customer
might
be
calling,
for
example,
your
customer
support
requiring
a
password
reset,
and
you
would
like
to
inform
your
your
customer
support
folks
whether
this
particular
user
has
had
a
history
of
some
suspicious
history
that
might
require
your
css
to
then
ask
more
questions
and
feel
more
careful
about
to
go
ahead
and
go
and
reset
in
this
account
for
this
user.
A
Now
the
risk
texas
api
is
only
just
prior
to
access
to,
or
this
is
just
the
two,
the
two
methods
that
we
provide
to
do
this
with
right.
You
want
to
get
a
list
of
the
risk,
detection
objects
and
you
all
want
to
read
the
properties
and
relationships
of
the
risk.
Detection
objects
right.
The
difference
in
bnt
want
to
just
get
all
the
users
that
have
been
affected
and
the
second
one
is
all
about
getting
the
specific
risk
profile
for
each
one
of
those
users.
So
we
think
this
can
be.
A
We
hope
this
can
be
quite
useful.
Let
me
look
through
the
questions
here
to
see,
if
there's
any
anything
that
we
ought
to
address
about
this
right
now.
Let's
see
we
have
here,
so
we
are
able
to
assign
risk
triggers
per
user
or
per
group
of
users.
Can
we
scale
different
risk
right
here,
such
as,
given
our
sweet
students
attending
the
company's
purposes?
A
It
is
also
possible
to
create
a
then
aca
policy
for
that
suite
of
users
that
can
be
proactively
more
aggressive,
or
maybe
it's
the
opposite,
the
proactively
more
permissive.
It
is
also
possible
to
have
your
ca
policies
trigger
based
on
location,
so
in.
In
effect,
you
really
could
create
what
I
think
you're
asking
following
a
set
travel
route.
A
I
think
that
might
end
up
being
a
little
more
than
you
want
to
manage,
but
if
you
wanted
to
say
on
tuesday
only
from
this
location
on
wednesday,
from
only
those
locations
on
thursday
from
this
location,
you'd
have
to
write
three
policies
on
tuesday,
wednesday
and
thursday,
because
you
might
want
to
add
to
that.
Let
me
know
if
that
that
sounds
right
to
you.
A
So
the
capability
is
there
not
not
the
capability
to
establish
a
you
know
a
set
pattern,
but
it
is
the
capability
to,
for
example,
approve
ellipsis
of
of
countries
for
which
they
will
not
be
traveling
over
the
next
week
and
only
from
those
countries.
Would
you,
then,
if
they're
not
coming
from
those
countries
that
you
expect
them
to
be
then
require
them
if
they
require
or
block
the
user,
because
anything
else
on
that
example?
Are
there
examples.
B
B
What
that
country
should
be
for
that
for
that
for,
like
for
that
group
of
name
locations,
so
you
could
do
that
and
there
like.
There
are
various
automation
options
which
you
can
use
with
the
apis.
But
there's
no
like
a
map
where
you
can
go
in
and
just
say
this
is
the
path
and
just
these
are
the
days
and
you
can
as
long
as
you
follow
that
path
and
the
the
days.
A
There's
another
question
here
about
risk
detection
that
I
think
would
like
to
address,
just
in
the
spirit
of
giving
you
fresh
information
that
you
care
about,
so
we
have
order,
ask
about.
Do
you
recommend
admins
to
look
over
each
risky
user
or
risky
signing
low
medium
high
and
take
an
action
that
has
confirmed
the
user
or
dismiss
it
or
just
let
the
user's
policy
in
signing
risk
policy
do
the
order
remediation!
A
Here's
what
I
would
say
we
did
not
design
the
system
so
that
a
single
person
has
to
necessarily
view
the
reports
and
proactively
do
something
about
them
right.
We
realize
that
in
most
environments,
that
is
not
something
that
that
any
of
you,
perhaps
in
the
car,
are
willing
to
go
to
work
or
want
to
invest
time
doing
so.
The
system
isn't
designed
so
that
you
create
automated
policies
and
you
tweak
them
over
time.
You
tune
them
to
the
right
audiences.
You
tune
them
to
the
right
situations
and
that
you
don't
have
to
worry
about
it.
A
So
I
would
recommend
that
you
do
not
count
on
a
human
reviewing
them
on
a
daily
basis.
However,
it
would
be
appropriate
that
if
there's
a
security
team
at
the
corporation
who
doesn't
or
a
risk
assessment
team
in
your
organization
that
they
do
on
a
habitual
basis,
do
review
a
particularly
high
risk
activity
and
and
kind
of
do
that.
Do
they
internal
review
us
to
say,
did
we
expect
this?
Was
it
mitigated
as
we
expected?
Is
there
an
incredible
spike
on
it
over
some
period
of
time?
That
tells
us
something
else
is
going
wrong.
A
More
importantly,
right
we're
only
talking
about
the
signing
portion.
All
right,
all
we
can
protect.
Is
your
front
door
right
what
your
users
do
when
there's
inside
it's
something
that
you
are
uniquely
able
to
do
right,
especially
with
your
consumer
applications,
so
in
any
meaningful
consumer
application
on
the
backend.
You
also
have
some
audit
and
some
tracking
of
what
are
the
users
doing
and
what
activity
seems
a
little
odd
like
changing
a
chip
in
addresses
too
often,
or
it
could
be.
A
You
know
changing
these
credit
cards
too
often,
there's
a
number
of
systems
that
you
already
have
that
together
can
best
give
you
the
picture
you're.
Looking
for
we're
really
concerned
about
the
front
door-
and
I
think
the
automated
way
is
the
way
that
would
be
probably
most
affected
and
that's
the
way
we
think
we
design
it
for
you,
because
would
you
add
to
that
yeah?
I
think.
B
Actually,
looking
at
it
every
day
is
not
probably
the
right
thing
to
do.
You
could
go
in
and
have
a
monthly
audit
or
a
weekly
audit
to
see
what
your
high
risk
users
are
if
you're
interested,
but
one
of
the
things
to
help
with
automations
which
we
have
done
is
we
have
integrated
connectors
for
identity
protection
in
power,
automate
platform
and
logic
apps.
So
if
you
want
to
build
your
custom
policies
or
custom
automations,
you
can
use
power
to
make.
B
You
can
then
pull
the
signals
from
your
app
and
then
decide
to
do.
Take
certain
actions
so
it'll
be
really
good.
If
you
have
a
chance
to
look
at
the
power
automate,
connectors
and
the
logic
cap
connectors
for
for
identity
protection
and
try
and
build
and
play
with
these
automations
of,
how
do
I
combine
these
signals
and
automate
them
instead
of
going
having
to
go
every
day
or
every
week
to
look
at
those
in
the
azure
portal?.
A
A
You
thank
you.
You
know.
We
really
do
think
that
we'd
like
to
give
you
the
information
that
you
need
to
to
manage
your
security,
but
this
automated
fashion
is
really
the
way
you
want
to
do.
You'd
rather
be
tweaking
it
over
time
than
than
thinking
that
you
were
you
rather
tweaked
the
policy
based
on
the
reports
and
the
outcomes
too
many
customer
calls
that
are
not
happy
right.
A
I
hope
that
does
not
happen
to
you,
but
be
watchful
for
that,
and
you
tweak
it
over
time
and
anytime,
you're
deploying
new
properties
or
you
have
a
customer
base
going
in
a
particular
set
of
countries.
Then
your
user
base
will
change
and
you
will
see
changes
on
this
as
well.
I
address
here
also
a
question
about:
do
you
use
low
medium
or
high?
A
Basically
from
our
our
team,
you
should
always
do
something
about
a
high
signal
medium.
You
should
do
something
depending
on
what
the
user
is
accessing
and
what
I've
got
from
the
team
is
that
low?
Typically,
it's
not
something
you
have
to
mitigate
it's
probably
more
something
to
observe,
but
that's
you
know
that
could
that
your
mileage
may
vary
depending
on
your
on
your
user
base.
A
Okay.
So
with
that,
I
want
to
take
you
through
a
quick
view
of
how
this
is
working
b2c,
first
and
and
we'll
do
this
fairly
quickly.
First
of
all,
b2c
is
very
much
of
the
end
user
experience
right,
as
I
think
you
guys
are
as
well
right
the
idea
of
it
being
look
and
feel
of
the
way
you
want
it
to
be,
and
the
ability
of
users
to
control
their
own
information
right,
but
it
all.
A
The
more
therefore
requires
that
you
are
sensitive
to
risky
signings,
because
the
signing
can
therefore
affect
an
account
and
its
information
right.
So
all
of
the
branding
and
the
look
and
feel
of
b2c
is
key
for
friction.
Feeding,
experience
right
the
way.
The
way
we
configure
b2c-
and
this
is
just
a
super
quick
recap
right-
is
that
for
each
application,
you're
able
to
build
specific
policies
and
now
we're
going
to
use
policy
in
two
different
words.
One
type
one
way
to
use
policy
is
what
is
the
experience
the
user
goes
through?
A
How
do
they
log
in
what
do
they
look
and
feel?
What
are
the
options
for
for
identity
providers?
Like
you
know
facebook,
or
do
you
have
subgoogle,
or
do
you
accept
an
email,
or
do
you
accept
the
user
id
that's
defined
in
a
sign
up
and
signing
policy
and
a
single
application
can
choose
which
one
of
these
two
to
operate?
This
is
important,
because
this
is
the
kind
of
capability
that
allows
you
to
therefore
change
experiences,
depending
on
what
a
customer
is
trying
to
do.
A
Your
app
can
decide
that
there's
one
signing
required
for
all
users
in
all
situations.
That
does
not
have
a
ca
policy,
a
conditional
access
policy,
and
it
can
also
decide
that
when
they
access
a
certain
portion
of
the
site,
the
application
is
going
to
require
a
re-off
right
that
will
go
back
to
to
b2c
and
b2c
will
now
check
the
current
signing
risk
and
if
something
is
required,
then
then
trigger
it.
I'm
just
giving
you
food
for
food
for
thought
of
things.
You
can
do
with
your
application,
especially
consumer
applications.
A
A
A
But
what
you
can
see
here
is
that
I'm
looking
at
a
month
of
history
of
detections,
remember
all
of
these
availability
apis
number
one
number
two
for
each
user
right,
I'm
able
to
review
what
ip
address
they
came
from
nothing
new
there,
the
specific
location-
and
you
can
see
here
a
number
of
examples
from
across
the
world
from
holland
netherlands
to
in
this
case
puerto
rico,
and
in
each
one
of
these
there
was
a
detection.
There
was
a
reason
why
this
I
was
added
to
the
list
in
this
case
was
an
unfamiliar.
A
Sending
properties
right
which
could
be
could
be
linked
back
to
the
browser
I
use
could
be
back
linked
to
the
location
I'm
from,
and
I'm
just
going
to
call
that
something
that
usually
doesn't
happen
happen
here
right
task
force
prey.
We've
talked
about
quite
a
bit
in
this.
In
this
conversation,
you
can
tell
the
password
spray
immediately,
triggered
a
high
risk
signal
right
and
then
look
at
a
number
of
anonymous
ip
addresses
used
and
I'll
bet.
You,
because
of
the
netherlands,
there's
a
good
chance.
A
There's
some
vpn
going
on
vpn's
being
used
here
and
they
were
assessed
as
medium
right
this
as
you
look
at
this
in
your
own
population,
you
can
better
assess.
Do
I
want
to
take
action
on
medium?
Do
I
want
to
take
action
or
no,
you
want
to
exactly
run
high
I'll.
Tell
you
right
now.
You
should
take
action
on
high,
but
it's
more
of
the
question,
whether
medium,
whether
you
follow
the
actual
medium
or
not,
and
it's
through
these
reports
that
you're
able
to
do
that
right.
A
So
this
is
the
full
list
and
we
earlier
showed
you
the
list
of
the
ones
that
apply
and
the
team
is
adding
new
signals
here,
all
the
time
just
to
make
it
more
transparent
to
you,
try
to
make
it
more
transparent
to
you.
What
is
it
that's
going
on
and
you
can
then
do
the
research
to
see
if
this
is
not
something
normal
with
your
particular
user
base,
but
I
won't
go
into
great
detail
here,
because
anything
else
you
add
on
this
page
that
you
should
call
out.
A
No,
I
think
you've
covered
well-
okay,
great
so
now
now
that
you've
seen
that
there's
some
activity,
you
want
to
prevent
right
because,
let's
be
clear,
unless
I
wrote
a
policy,
this
high
risk
was
nothing
happened
with
it
right.
We
merely
detected
it.
We
flagged
it,
but
if
the
user
met
the
conditions
you
described
like
provided
mfa,
they're
logged
in
correctly
they're
still
coming
into
your
your
service.
This
is
entirely
on
your
control.
So
what
to
do
about
it?
A
What
we
provide
you
with
is
the
ability
to
do
a
provided,
define
a
conditional
access
policy
right.
This
is
the
conditional
access
panel,
and
this
is
the
the
a
section
that
biggest
and
his
team
can
own
right.
It's
all
about
the
creation
of
a
new
policy
and
very
quickly.
I
just
want
to
point
out
a
few
things
here:
the
creation
of
a
new
policy
where
you're
able
to
identify
you
know
to
which
users,
this
supplies
or
groups
which
specific
applications
should
be
protected
under
what
conditions
and
if
those
conditions
are
met.
A
A
A
They
have
decided
that
whenever
somebody
accesses
my
account,
I
want
am
I
I
want
them
to
be
mfa
right
now.
I
want
to
be
mfa
when
I
access
my
account
to
provide
a
higher
security
level
right.
The
way
this
is
done
is
by
assigning
users
to
an
azure
active
directory
group
right.
You
can
look
that
up
how
to
do
that,
but
I
created
a
short
directory
group.
A
A
Then
I
then
selected
which
applications
and
I
specifically
selected
these
two
applications.
We
were.
We
were
talking
to
a
one
of
the
top
car
management
car
management,
car
manufacturers
in
the
united
states
about
this,
so
we
simulated
a
car,
unlocking
app
and
a
car
management
service.
So
only
these
two
applications
will
this
policy
applied
to,
and
then
we
set
the
condition.
The
condition
should
be
none
right.
In
other
words,
we
always
want
this
to
happen.
For
this
particular
set
of
users.
A
I
want
the
mfa
method
to
be
emailed,
not
that
I
could
have
chosen
sms,
but
I
know
that
these
customers
have
not
provided
all
provided
phone
numbers
in
the
past,
so
I'm
going
to
use
email
as
the
mfa
method
right
and
the
mfa
enforcement
I'm
going
to
make
it
happen
only
when
the
conditional
access
policy
requires
it
right.
This
is
the
default
approach
else.
I
could
have
said
no
matter
what
the
conditional
access
policy
says.
I
always
want
to
mfa.
That's
what
this
would
have
required.
A
So
if
I
were
to
run
the
usoflow
and
let's
go
ahead
and
select
the
car
car
management,
we
talked
about
in
this
demo,
current
locking
app-
and
I
just
run
the
user
form,
just
simulating
the
experience
with
your
application,
calling
b2c
it
already
pre-loaded
my
my
credentials,
because
I
have
done
this
before
and
I
push
sign
in
right
now.
It
simulates
b2c
apps,
approving
the
login
and
send
the
information
back
to
your
application.
As
you
can
tell
here,
there
was
no
nothing
blocking
me.
A
Why
and
I'll
show
you
why
that
was
on
purpose,
but
the
token
was
sent
to
your
application,
saying
yes,
this
user,
jose
he's
allowed
to
come
to
your
application,
his
information
about
this
user.
The
reason
it
didn't
trigger
is
because
I
have
not
turned
on
the
policy
right,
so
I'm
back
in
the
conditional
access
screen,
I'm
going
to
turn
on
the
policy
I'm
going
to
save
it
and
by
saving
the
policy.
Now
it's
active
right.
So,
let's
do
that
again:
let's
go
ahead
and
log
in
one
more
time
and
and
run
user
flow.
A
A
Obviously
you
can
control
everything
on
this
page,
so
you
can
say
whatever
you'd
like
to
say,
I'm
going
to
say:
yep,
send
me
a
verification
code
and
I'm
going
to
look
for
my
email
to
see
that
I
receive
the
verification
code
and
this
this
becomes
the
second
check
or
the
way
in
which
b2c
enforces
a
higher
level
of
security
using
conditional
access
right.
This
could
have
all
have
been.
I
got
a
code,
I
the
email
with
the
code
and
I'm
going
to
put
in
my
code.
A
B
B
Yep
or
you
could
you
could
just
do
sign
ins,
so
if
you
could
do
sign-ins,
okay
on
the
left
yep,
so
if
you're,
if
you're,
if
you
have
any
you
know
someone
calling
up
and
saying
this
is
not
working,
that's
not
working
at
least
make
sure
that
you
can
go
to
that
user
and
the
sign
in
associated
to
that
user.
So
you
would
be
able
to
see
all
the
sign
in
associated
to
that
user.
You
can
see
where
the
issues
are.
You
can
go
to
conditional
access
here.
B
B
So
you
will
see
report-only
ins
and
you'll
see
the
policies
which
are
impacted,
while
those
sign-ins
are
happening
so
do
try
when
you're,
enabling
the
policy
enable
them
in
report
only
first
to
see
the
impact
of
the
policy
before
you
turn
them
on
and
go
to
the
users-
and
you
know,
see
the
user
sign-ins
to
see
how
the
policies
are
getting
evaluated
for
those
sign-ins.
So
look
at
the
conditional
access
tabs
inside
the
sign-in
and
also
the
report-only
tab
inside
the
finance.