Which ADA Assessment Does Your Product Need?
Most companies need more than one, and the order you do them in matters. Match the assessment to where your code runs, see the combinations that actually occur, and avoid the routing mistake that sends a server component to the wrong profile.
App Defense Alliance
Most companies need more than one, and the order you do them in matters. A decision guide with no jargon.
In short. Match the assessment to where your code runs. Mobile app means MASA. Web app or API means CASA. Software installed on a user's own computer means DASA. Anything running on your cloud infrastructure, including your back end, brings in the Cloud App and Config profile. Most real products touch two or three of these.
What is this decision actually about?
The App Defense Alliance, usually shortened to ADA, is an industry group that sets security standards for apps. It began at Google in 2019 and moved to the Linux Foundation in 2024, so it is no longer run by any single company. Google, Meta and Microsoft sit on its steering committee.
ADA runs several assessment programmes rather than one, because a mobile app, a web API and a piece of installed software fail in genuinely different ways. The requirements are different because the threats are different.
The mistake teams make is thinking of this as choosing one programme. Usually it is not a choice. Your product has several parts, each part runs somewhere, and the assessment follows the part rather than the product.
Useful to know. All of these requirement sets are published free of charge at github.com/appdefensealliance/ASA-WG. Before you decide anything, you can read the actual requirements for each profile and see how much of your product each one touches. Each profile's specification opens with a scope statement, and reading those four scope statements is about twenty minutes of work that will settle most of this article for your specific product.
Match the assessment to where your code runs
| If you have | The assessment is | Why |
|---|---|---|
| A mobile app on Google Play or a similar store | MASA | The app runs on a device you do not control, so the requirements focus on local data, platform permissions and traffic protection. Covers Android, iOS and Meta Quest. |
| A web application users log into in a browser | CASA | Runs on your infrastructure, reached over the network. Requirements focus on authentication, access control and input handling. |
| An API other software calls, including your own mobile app | CASA | APIs are explicitly in scope and are frequently less well protected than the web interface in front of them. |
| Software customers install on their own computers | DASA | Runs on a machine the user controls, so requirements focus on privilege, updates, signing and local storage. Installers and updaters are explicitly in scope. |
| The back end behind any of the above, and the cloud accounts it runs in | Cloud App and Config | A distinct profile with its own specification, built on the CIS benchmarks and covering AWS, Google Cloud and Azure. Configuration failures, not code failures, cause most real-world cloud data exposures. |
The routing mistake worth avoiding. It is natural to assume that because DASA covers software running on somebody else's machine, it covers your server component too. It does not. The DASA specification's scope table places backend server infrastructure out of scope and directs it to the Cloud profile. DASA is the desktop client, its installer and its updater. If you scope a server component into a DASA engagement you will be told it does not belong there, after you have paid for the scoping conversation.
The combinations that actually occur
Here is what real products need, which is rarely a single programme:
| Your product | What you probably need | Notes |
|---|---|---|
| A mobile app with a cloud back end | MASA + CASA + Cloud | The commonest case by far. The app, the API it talks to, and the infrastructure behind it are three separate attack surfaces. |
| A web-only SaaS product | CASA + Cloud | The application and its infrastructure. Add MASA later if you ship a mobile client. |
| A desktop product with a cloud sync service | DASA + CASA + Cloud | The client goes to DASA; the sync API goes to CASA; the infrastructure goes to the Cloud profile. Three parts, three profiles. |
| An API-only platform product | CASA + Cloud | No user interface to test, but be precise about which endpoints are in scope. |
| A mobile app requesting sensitive platform data | MASA + CASA | Where a platform has made an assessment a condition of the access you need, that one has a date attached. Confirm the current condition in the platform's own developer documentation, not in a summary like this one. |
| Installed desktop software, no cloud component | DASA only | Genuinely single-programme, and increasingly rare. |
Who is required to do which
Requirement comes from three places, and it helps to keep them separate in your head.
- A platform gate. The strongest form. A platform can make an assessment a condition of granting access you depend on. You do not get the access without it, so it is effectively mandatory and it has a date attached to your launch. Because platform conditions change, verify the current one in that platform's own developer documentation rather than in any third-party description.
- A contract or procurement condition. An enterprise customer, a bank or a platform partner makes independent testing a condition of purchase or integration. Just as binding commercially, and usually negotiable on timing but not on substance.
- Your own judgement. Nobody has asked, but you handle sensitive data, or you are tired of answering security questionnaires one at a time, or you want to know what an outsider would find. This is a genuine investment decision and it is reasonable to defer it.
In short. No ADA assessment is required by law anywhere. If somebody tells you MASA or CASA is a legal obligation, they are either confused or selling. What is true is that platform gates and customer contracts can make them practically unavoidable.
The second question: which assurance level
Choosing the profile is only half the decision. The other half is the assurance level, which determines whether you need a laboratory at all. It is entirely possible to need three profiles and require a laboratory for only one of them.
The repository describes three levels: AL0, self assessment; AL1, where you run the tests and an independent assessor reviews your evidence; and AL2, where the laboratory tests directly. Establish the level alongside the profile, because a plan built on the wrong assumption here will be wrong about both cost and elapsed time.
Check the levels per profile. Not every profile offers every level. The MASA specification, for instance, presents only AL1 and AL2 and does not mention AL0, even though the repository README describes three levels programme-wide. Read your own profile's specification before you assume self assessment is available to you.
Which order to do them in
If you need more than one and cannot do everything at once, this sequence causes the least waste.
Step 1 — Anything on a platform gate, first
If an assessment is blocking access you depend on, nothing else competes with it. It has an external date and a direct revenue consequence.
Step 2 — Cloud configuration, second
Usually the cheapest, the fastest, and the one most likely to find something genuinely dangerous. It also frequently surfaces problems that would have failed your CASA assessment anyway, so doing it first saves money downstream.
Step 3 — CASA, third
Your API is the shared attack surface behind both your web and mobile clients, so fixing it benefits everything else.
Step 4 — MASA or DASA, last
Client-side assessments. Valuable, but the findings tend to be narrower in blast radius than an exposed database or a broken access control on your API.
One exception to that order: if a specific customer contract names a specific assessment, do the one they named first regardless of what would be technically optimal. The commercial deadline wins.
What all of them have in common
Whichever you need, the shape is the same, and this is worth knowing because it means preparation transfers between them:
- the requirements are public before you start, so you can self-assess first;
- an independent authorised laboratory does the testing, not you and not a consultant of your choosing;
- you get a verdict of Pass, Fail or Inconclusive against each individual requirement, not an overall score;
- an independent reviewer inside the laboratory checks the work before anything is released;
- failures come with remediation guidance specific to your application;
- you fix and retest, and a defined number of retests is usually included;
- validation lapses after a period and has to be renewed, so confirm the renewal period for your profile;
- no fee may depend on the verdict.
Frequently Asked Questions
Click any question to expand the answer.
QOur product has a server component customers deploy themselves. Is that DASA?
No. The DASA specification's scope table places backend server infrastructure out of scope and directs it to the Cloud profile. DASA covers native desktop applications, Electron and CEF desktop applications, and application installers and updaters. If you have a desktop client and a server component, the client is DASA and the server side is assessed separately.
QDo we always need a laboratory?
Not necessarily. At AL0, where a profile offers it, the assessment is a self assessment. At AL1 you do the testing and an independent assessor reviews your evidence, so a laboratory is involved but does less. Only at AL2 does the laboratory do the testing itself. Establish your level before assuming you need to commission anybody.
QCan one laboratory do all of them?
Sometimes, but check. A laboratory is authorised for specific assessment types, and authorisation for MASA does not automatically extend to CASA or DASA. ADA ties the proficiency evaluation to the specific profiles a laboratory offers. Ask which types a laboratory is authorised for and confirm it against ADA's published list rather than taking the answer on trust.
QIs it cheaper to do several at once?
Often yes, because scoping, contracting and communication overhead is shared. Ask for a combined quote and compare it against separate ones. Do not let bundling push you into assessing something you do not need yet.
QDo they all renew at the same time?
Not automatically, and staggered renewals are a nuisance to manage. If you are doing several, ask whether they can be aligned to a common renewal month. Some laboratories will accommodate it.
QHow does doing more than one help us?
It closes the gap that a single assessment leaves. A team that passes MASA and has an unassessed API has protected the part attackers care least about. The API and the cloud configuration are usually where the serious exposure is.
QDo we need to do these regularly, all of them?
Yes, each renews on its own cycle. The cloud configuration one deserves continuous automated monitoring in addition, because configuration drifts without any code change.
QWe are early stage. Should we wait?
If no platform gate and no customer is asking, a reasonable position is to do the cloud configuration review now, because it is cheap and catches dangerous things, and defer the formal programme assessments until somebody asks or you handle sensitive data. Do not defer the underlying security work, only the formal validation.
QWhat if our product does not fit any of these neatly?
Read the scope statement at the front of each profile's specification, then describe where your code runs and ask a laboratory or ADA directly. Odd architectures do exist, and guessing your way into the wrong programme wastes a lot of money. Embedded devices, browser extensions and command-line tools are the usual awkward cases.
QIs there an AI profile we should be planning for?
There is an AI Profile folder in the repository, but the work is still developing and there is no settled requirement set to plan against. Watch the releases page, and treat anybody describing firm AI profile requirements today with caution.
QWho actually sees the result?
That depends on the programme. Some results appear as a badge or a note on an app store listing that your users can see. Others are shared with the platform that asked you to get assessed, and are not public. Ask the lab what will be published before you start, and get it in writing. A good lab will not publish anything about your app without your written consent.
QWhat if we disagree with a finding?
You can dispute it. An authorised lab has to have a documented dispute process, and the person who decides your dispute must not be the person who made the finding. If the verdict changes, the lab has to update the report with ADA. Ask to see the dispute process before you engage a lab.
QDoes a pass mean our app is secure?
No, and be careful of anyone who tells you it does. A pass means your app met the requirements that were tested, in the version that was tested, on the date it was tested. It is not a guarantee. It is a meaningful, independently checked baseline, which is a different and more honest thing.
QCan we use our own internal security team instead?
Not for the formal validation. The whole value of these programmes is that the tester is independent of the developer. Your internal team is exactly the right people to do the preparation work and the fixing, but the validation itself has to come from an authorised lab.
QCan the lab help us fix the problems it found?
It can tell you what to change, and it should: specific remediation guidance for each failed requirement is a programme requirement, not a favour. What it must not do is implement the fix for you, because then it would be validating its own work. Advice yes, hands on your codebase no.
Related reading
Once you know which profiles apply, each one is covered in full: MASA for mobile apps, CASA for web applications and APIs, DASA for desktop software, and the Cloud App and Config Profile for the infrastructure underneath.
Then: work through the checklists yourself, see what the laboratory actually does, learn how to choose an authorised laboratory and what its accreditation means, and follow the four-week preparation plan. If you want to check any of it yourself, start with how to verify anything you read about these programmes.
About Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India. We have been doing web, mobile and cloud security testing since 2018.
We are currently building our laboratory management system to ISO/IEC 17025:2017 and working towards authorisation as an App Defense Alliance Security Test Laboratory. We are not an ADA-authorised laboratory today. We will say so plainly on this page until that changes, because you should be able to trust what a security firm tells you about itself.
What we can do for you right now:
- Working out which profiles you actually need. This is the conversation in this article, applied to your architecture, and it costs you nothing to have. Getting it wrong is the expensive part.
- Readiness testing. We test against the relevant requirement set and tell you what would fail, before you pay for a formal validation. Depending on the profile that is mobile application, web application, API or cloud configuration testing.
- Fixing what we find. Guidance specific to your application, naming the component and the change. Where the cause sits in the source, secure code review is the faster route; where it sits in the design, threat modelling is.
- Evidence preparation. We help you assemble the documentation, architecture information and test accounts an authorised laboratory will ask for, so your validation does not stall on paperwork.
Please note. One thing we will tell you up front: if we do your readiness work, we cannot later be the laboratory that performs your formal ADA validation. Our impartiality rules stop us from validating an application we have already advised on. We would rather you knew that at the beginning than after you had paid us. If your priority is the formal validation, we will point you at an authorised laboratory and stay out of the way.
Attribution and source
Profile names, scope statements and assurance level descriptions in this article are drawn from material published by the App Defense Alliance in the ASA-WG repository at github.com/appdefensealliance/ASA-WG, licensed under Creative Commons Attribution-ShareAlike 4.0 International. The routing advice, the recommended sequence and the commercial judgements are our own.
Programme requirements are versioned and they change, and platform conditions change independently of them. Before you rely on any specific detail in this article, check the current published requirements in the App Defense Alliance repository and its releases page, the certification information on the App Defense Alliance website, and any platform condition in that platform's own developer documentation. Where this article describes how a process generally works, that shape is stable. Where it would matter to you whether a specific claim is exactly right, confirm it at the source.
Adayptus Consulting
Application Security Testing, Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India, working across web, mobile and cloud security testing since 2018. The firm is building its laboratory management system to ISO/IEC 17025:2017 and working towards authorisation as an App Defense Alliance Security Test Laboratory; it is not an ADA-authorised laboratory today.
On This Page
- What is this decision actually about?
- Match the assessment to where your code runs
- The combinations that actually occur
- Who is required to do which
- The second question: which assurance level
- Which order to do them in
- What all of them have in common
- Frequently Asked Questions
- Related reading
- About Adayptus
- Attribution and source
