Anil John
Making Digital Services Secure and Trustworthy

Anil John

HOW-TO Incorporate Risk Management into Assurance Level Determination

 Tweet  Share  Comment  Print  Email

My earlier blog posts on conducting a risk assessment to determine acceptable credentials as well as handling mismatches between assurance level(s) available from authentication assurance providers and assurances needed by a relying party individually addressed the same topic, but from different perspectives. This blog post provides a simple framework that incorporates both aspects within the specific context of identity federation.

The typical evaluation sequence, based on OMB E-Authentication Guidance for Federal Agencies (OMB-M-O4-O4) (PDF), involves conducting a risk assessment, mapping risks to applicable assurance level, selecting appropriate credential based on technical guidance, validating the system has met the required assurance level; rinse and repeat.

The concern I have with the approach within the context utilizing federated credentials is that, it is a pure, unadulterated technical perspective that does not take into account many non-technical factors that drive service delivery. So, a variation on the current model is:

In the above, the process used to identify the needed authentication assurance level based on the impact of consequences of an authentication error on privacy, inconvenience, damage to reputation, harm to organization and programs, financial liability, crime and safety remain the same.

The next steps are specific to identity federation in that what is being sought by the relying party are credential service providers that can meet its assurance level needs.

Where I have diverged from the traditional sequence is the addition of an explicit step on managing uncovered risk. I will point you to the previous blog post on this topic on the assurance level need mismatches for what I mean by uncovered risk. At the same time a question that often comes up at this time is: “If the need for assurance by the RP is a 2+, instead if implementing a risk management strategy to accept a Level 2 credential, why not simply move up and require a Level 3 credential?”

A very valid and purely technical answer is “Yes, that is the way to go”. But this is where non-technical factors come into play. In speaking with colleagues (and not just in the USA) who have gone through this, the reality is that there are other factors that need to be considered, such as:

  • What if a CSP that can meet the needed assurance level is not available? And there is an overriding business need to still offer the service to customers using a lower assurance credential?
  • What if the credential cannot be obtained at a price point that is acceptable?

When these situations arise, the RP needs to make some clear, and often hard, choices on how they will manage the risk of using a lower assurance level credential for a higher level transaction. The choices are to accept the risk, transfer the risk typically using some sort of financial instrument, reduce the risk using compensating controls, or simply choose to avoid the risk by not going down that path.

I’ve also added a continuous monitoring step into the process as I believe that we need to incorporate on-going re-proofing and real time analytics into the authentication mix, given the extremely fluid and evolving threat environment that is the internet.


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog ( The opinions expressed here are my own and do not represent my employer’s view in any way.

By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a Public Interest Technologist. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone