You could build your own Authorization solution…but should you?

Axiomatics   ·   Tuesday, November 30th, 2021

Having spoken with many customers about the challenges around authorization, one of the themes that has come up time and time again is whether an organization should simply build their own authorization system into applications versus buying an external solution.

In fact, I feel like I have talked about this so much that when our team suggested I write about this, my first reaction was to say everyone has heard all of this before.

But as we discussed it further, I realized there are some new considerations that have not been discussed much in the past so I’d like to cover them here.

Before diving into the new things organizations should consider, let me quickly recap my thoughts on two typical questions usually raised.

Will you get enough of a return on your investment to make it worthwhile?

Building an engine that can dynamically process authorization policies based on various attributes is not something that can be created overnight. It requires significant time, expertise and staff resources to complete.

Even when the authorization requirements are so ingrained in what your business offers (as several of our customer use cases have been), it likely doesn’t make sense to invest the time and resources required to build your own from the ground up.

Can you build once but reuse on multiple applications across your network?

The need to securely share your assets and ensure appropriate need-to-know access is not a static, build-once-use-for-ever engineering challenge.

The challenge is going to evolve over time due to new compliance regulations, new threats and new application requirements.

It will be crucial to ensure the authorization solution you build will be flexible enough to be leveraged by other business areas and that future needs can be incorporated with relative ease.

If not, what you build will be a one-off and you will need to repeat the process again for the next use-case. How much is that going to cost you in time and resources?

While those are the usual questions people raise, there are some new ones I’ve started to ask after observing some new trends arise. They may seem like common sense after the fact, but they are often overlooked initially and can be quite costly in the long run.

Is this something your developers are really passionate about?

The fact is, good developers are in demand and there are lots of employment opportunities.

A recent article I read mentioned the turnover rate in the tech industry is a sky high 18.3%. If you do a little more digging, you’ll see a number of articles over the last couple of years referring to the average tenure in tech being under three years, and even less for some positions.

I’m not suggesting you only let your development team work on things they want to, but I will say I have been in meetings where the discussion of shifting the project focus for a team of developers has quickly evolved into an HR discussion on whether or not the company might lose one or more of the team because “it’s not an area that interests them.”

Many of the personality traits organizations look for when hiring developers such as being passionate about the technology, having an eagerness to learn new things, and a creativity to consider new ways of doing things are the same reasons why someone may opt to leave if they are asked to work on an area they are not passionate about, have already learned about in the past or does not offer much opportunity for creativity.

Each time you lose a developer whether through turnover or due to an internal transfer to another project, finding a replacement can end up costing your organization a great deal.

In a relatable example, how many of you enjoy doing electrical work on your house such as replacing or adding an electrical outlet?

I’m sure if given proper instructions and time, we could all do it (perhaps not as well or as safe as a professional), but is it something we want to work on?

Personally, I get very nervous whenever I have to do anything that involves touching electrical wiring. I don’t want to make any mistakes that will put me in danger or be the cause of a fire.

I really like my role at Axiomatics. If someone came along and passed me a toolbox and said I need to pause whatever I was working on and instead go install a new electrical outlet in our office, I can assure you I’d not be very happy about it.

How comfortable will the regulators be with your homegrown solution?

This is the question most organizations had not considered initially but is important to ask because I’ve seen how this can add a great deal of time, effort and failures in extreme cases, during an audit.

When an auditor poses a question as to how you solve for a specific aspect of a regulation and the answers are either:

“We’re using this well known industry recognized solution to solve that challenge.”

Or

“We made our own custom solution for that in-house.”

Which of the above is going to generate more auditor scrutiny?

With the first answer, they are likely familiar with the way it works, the level of detail it can capture and they’ve probably had lots of exposure to it in previous investigations.

With the second answer, they’re not going to be familiar with what you’ve created. They are going to have a number of questions about how it is secured, what information is stored where, who can affect any changes, and what the controls are etc.

Additionally, as I mentioned earlier, there is a strong likelihood that whoever built your in-house solution is no longer with your company due to the high turnover rate in that profession.

As crazy as it sounds, it’s not uncommon for companies to be stuck using an older tool as-is and not have any ability to make changes to it as the lead developer who created it has moved on. If the person who developed your in-house solution is still with your organization, keep in mind you are now going to need to have that person answer all the auditor’s questions and hope they make the auditor feel comfortable enough to check that box.

Failing an audit or being faced with a finding that needs to be addressed as soon as possible can be quite costly.

The bigger picture

Obviously as I work for Axiomatics, one could argue that my opinion on this matter is somewhat biased.

Yes, I admit it, I do think you should buy as opposed to building an authorization solution.

However, considering the Axiomatics team has been tackling this challenge since 2006, it should give you a sense of why governments and enterprises continue to rely on our best in class products and expertise to enable them to protect critical assets, meet strict regulations, reduce costs, and improve collaboration.

Aside from all the questions I raised above about time, resources and audits, there’s one question I didn’t ask you…

Do you want to benefit from over 15 years’ worth of research and development to leverage a solution that enables you to centralize, standardize and scale dynamic access control across your entire organization?

If so, then we should talk because I bet we can help you save money in the long run and help your business grow.