We’re all getting used to using MFA (multi-factor authorization) when we log into systems. For example, Google sends me a text message, so I have to use my password and have my phone handy if I want to log into a new browser, or we all get emails sometimes to verify that we did, indeed, want to log into something and follow a link to approve access.

But all we’re doing is making it harder to log in with no consideration for what you do after you log in. The funny thing about Google MFA, for example, is that I don’t even remember the last time I logged into Google. Whether I upload YouTube videos, check my Gmail, review my photos, or work on a Doc, that one login I did a long, long time ago suffices.

The way hackers work is to leverage conveniences like a persistent single sign-on. Even if you had to enter a code from a text message six months ago — that was six months ago! Over time, the risk of this original authentication should be degraded. It doesn’t matter that the original login was verified with a second factor, the authorization type is just one value in a long equation you should be thinking about to calculate the risk or your transaction.

auth type + auth time + transaction type + device + location + identity = risk

We should assign a weight to each of these factors, so think of running a calculation like this:

Auth Type = two-factor auth = 5 points
Auth Time = six months ago = 50 points
Transaction Type = Google Pay = 75 points
Mobile Device = 35 points
Never-Before-Seen Location = 50 points
Risk Score: 215

Sure, that original MFA-driven login only contributed five points towards the risk, but we need to look at a LOT more than “did they use MFA when they logged in?” Now we create some security policies that map to risk scores:

Risk LevelRemediation
<50None
50 – 75Require Knowledge Factor Login
76-100Require Fresh MFA

Notice that we include identity in the calculation — these could be OAuth scopes or user entitlements, but the idea is that you should account for the identity of the user, service, or thing that is trying to execute a transaction. Maybe it’s a service account used for load balancing that you want to ignore, or maybe it’s a person who self-registered and needs additional scopes added to be trusted.

Now we factor in that identity, and our need changes dramatically:

Auth Type = two-factor auth = 5 points
Auth Time = six months ago = 50 points
Transaction Type = Google Pay = 75 points
Mobile Device = 35 points
Never-Before-Seen Location = 50 points
Scope for Test Account = -200 points
Risk Score: 15

Remember, security is a constantly shifting set of variables which can add – or remove – risk. It’s important to not only have tools like MFA to add to the calculation, but also to be constantly evaluating all the data points available, not just whether someone proved they were who they said they were once upon a time.

Are you looking for an identity management system you can trust with your cloud security? Explore Cloudentity. We help you establish a zero trust system for every service, user, and thing, protecting not only traffic into your datacenter, but also within it.

Explore our site to learn more about our API security solution for every stage of your business, find more resources here on our blog, and contact a member of our team to get started. See how easy API security can be with Cloudentity!