MASA: Mobile App Security Assessment Explained

Q: Does a MASA pass mean our app is secure?

No. 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.

What the Mobile Application Security Assessment is, who has to do one, what the laboratory actually does to your app, and how often you have to repeat it. Covers Android, iOS and Meta Quest.

App Defense Alliance

What the Mobile Application Security Assessment is, who has to do one, what the laboratory actually does to your app, and how often you have to repeat it.

In short. MASA is an independent security check of a mobile app against a published standard. It is voluntary unless a partner or platform has made it a condition. If you pass, Google Play can show an independent security review note on your listing. It has to be renewed every year.

What is this?

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.

MASA stands for Mobile Application Security Assessment. It is the App Defense Alliance programme for mobile apps, and it covers Android, iOS and Meta Quest applications. Stripped of jargon, it is this: an independent laboratory takes your app, works through a published list of security requirements, and issues a report saying which ones you met and which you did not.

In short. MASA is not Android-only, which is a common misconception. The requirement set covers iOS and Meta Quest as well. The platform is encoded in the first digit of every requirement identifier, and the Android and iOS requirement sets run in parallel rather than overlapping. If you ship on two platforms, plan for close to double the work, not the same work applied twice.

Three things make it different from hiring a security consultant.

The list is public. The requirements come from the OWASP Mobile Application Security Verification Standard, written as MASVS. OWASP is a non-profit that publishes open security standards. You can download it and read exactly what you will be tested against before you speak to anybody. Nobody can move the bar during the engagement.
The tester is accountable to somebody other than you. A lab has to be authorised by ADA, and part of that is holding accreditation to ISO/IEC 17025. That means an accreditation body inspects the lab itself: its competence, its records, its independence. What it inspects, and what accreditation does not mean, is set out separately. A consultant answers to you. A lab answers to its accreditation body as well, which is precisely why the report carries weight with third parties.
The output is a verdict, not an opinion. You get Pass, Fail or Inconclusive against each requirement, with evidence behind each one. Not a narrative report with a risk rating somebody invented.

ADA does not test apps itself. It publishes the requirements, then authorises independent laboratories to do the testing. A lab has to earn that authorisation, and part of earning it is holding accreditation to ISO/IEC 17025, the international standard for testing laboratories. What that accreditation actually demands, and how to read a laboratory's scope, is worth knowing before you engage one. The point of the arrangement is that the people judging your app have no commercial interest in the answer.

Why it exists. The short version: your users and your enterprise customers cannot tell a carefully built app from a careless one by looking at it. MASA is a way of making the difference visible, checked by somebody with no stake in the answer.

Who is required to complete it

This question gets muddled because there are three different answers and people run them together. Nobody is required by law. Some organisations are required by a platform or a contract, which in practice is just as binding. Everyone else chooses.

Who you are	Is it required?	Why
An app requesting sensitive Google Play data disclosures, or where a platform has asked for it	Effectively required	Not a legal duty, but the platform has made it a condition. Treat it as a hard deadline.
A vendor whose enterprise customer has made independent testing a purchase condition	Effectively required	Your contract or your procurement process says so. Missing it loses the deal.
Finance, health, identity or payments apps	Strongly advisable	Users are cautious and regulators are interested. The report answers questions you will otherwise answer one at a time, forever.
A business-to-business app facing security questionnaires	Strongly advisable	One independent report replaces a great deal of repetitive form filling.
A consumer app handling little sensitive data	Optional	Judge it on whether the findings and the trust signal are worth the cost. Many such apps reasonably decide not yet.
An internal-only app never distributed publicly	Usually not needed	The programme is aimed at distributed apps. Your effort is better spent on ordinary mobile application security testing.

The distinction that matters in practice: if a platform or a customer has made the assessment a condition of something you need, treat it as a hard requirement with a date attached. If nobody has asked, it is an investment decision, and you should judge it on whether the findings and the report are worth the cost to you.

In short. Nobody is legally required to do MASA anywhere in the world. If someone tells you it is legally mandatory, they are either confused or selling something.

The checklist is public, and free

This is the most useful thing to know before you spend any money, and most developers do not know it. The App Defense Alliance publishes its requirement sets openly on GitHub. You can read the exact bar you will be measured against, work through it yourself, and fix what fails before engaging anybody.

What	Where
Repository	github.com/appdefensealliance/ASA-WG
This profile's folder	/MASA
Version history and releases	github.com/appdefensealliance/ASA-WG/releases
Licence	Creative Commons Attribution-ShareAlike 4.0

The MASA folder publishes two documents. The MASA Specification is the requirement list: an identifier and a one-line description, and deliberately nothing more. The MASA Test Guide is the one you actually want, because for each requirement it gives the description, the rationale, the evidence you must submit, the test procedure, the acceptance criteria and any scope limitations.

The key point. Read the Test Guide, not just the Specification. The Specification tells you a requirement exists. The Test Guide tells you what evidence will be accepted, which is what determines whether your self-assessment succeeds. Working through the checklists yourself covers how to read a requirement entry field by field, and what evidence a reviewer accepts.

MASA requirement identifiers have four levels: platform, then domain, then control, then the specific test. So 1.1.1.1 is Android, storage, first control, first test. Once you know that, you can navigate the whole set.

Assurance levels: how much of the work is yours

How much you do, versus how much a laboratory does, depends on the assurance level. This is the single biggest driver of what an assessment costs you, so establish it early.

Level	Name	Who tests	Who checks
AL0	Self assessment	You. Described as being for low risk products.	Nobody independent
AL1	Developer Tested, Lab Reviewed	You run the test cases and submit evidence.	An independent assessor confirms your evidence is complete and sufficient
AL2	Lab Tested	The laboratory tests your product directly.	The laboratory, with its own independent internal review

AL1 is the level most developers meet, and it is worth being precise about what it asks. You are not signing a statement that you comply. You are running the test procedure and producing evidence that demonstrates it, and a reviewer then judges whether that evidence is sufficient. Thin or ambiguous evidence gets sent back, and every round trip costs you time.

Confirm this. One point to confirm rather than assume. The repository README states plainly that there are three assurance levels and describes AL0 as self assessment for low risk products. Some individual profile specifications, however, present only AL1 and AL2, which may mean AL0 is not offered for every profile. Check which levels apply to yours before you plan, because it determines whether you need a laboratory at all.

What gets tested

The MASA requirement set is organised into eight domains for each platform: storage, crypto, auth, network, platform, code, resilience and privacy. In plain terms, the lab is trying to answer these questions about your app:

Area	The question being asked
Data storage	Does the app leave sensitive data lying around on the device where another app, or a person holding the phone, could read it?
Cryptography	When the app protects data, does it use proven methods correctly, or has somebody invented their own?
Authentication	Can somebody get into an account they should not reach, or stay logged in when they should have been logged out?
Network communication	Is traffic properly encrypted, and does the app notice if somebody tampers with the connection? This is also where the API behind your app starts to matter.
Platform interaction	Does the app ask for more phone permissions than it needs, or expose internal features to other apps on the device?
Code quality	Does the app handle bad input safely, and are its third-party components up to date? Where the cause sits in the source, secure code review is the faster route to a fix.
Resilience	How hard is the app to tamper with or reverse engineer? This area applies mainly to apps with a strong reason to resist attack, such as payments.
Privacy	Does the app collect, use and disclose personal data consistently with what it tells users, and does it avoid collecting more than it needs?

Not every requirement applies to every app. Agreeing which ones do is part of the scoping conversation at the start, and whatever is excluded gets recorded and disclosed in the report.

What the laboratory actually does

Most developers have never seen inside a laboratory engagement, and the phrase independent assessment hides a lot of specific process. The essentials are below. For the whole engagement phase by phase, including the acceptance checks, the evidence standard and the independent review, see what the laboratory actually does.

Before the lab is allowed to accept the job

An authorised lab cannot simply take your money and start. Before it accepts, it has to satisfy itself of several things, and record that it did:

Competence. It has people qualified for your assessment type. ADA specifies which certifications the engagement team must hold, and a lapsed certification does not count.
Capacity and tooling. It has the qualified tools and the test environment your mobile app needs, and the time to do the work properly.
No conflict of interest. This one matters to you. A lab that has previously assessed or advised on your application, or that helped you build it, is barred from validating it. If a firm offers to fix your app and then certify it, that is not an arrangement an authorised lab can make.
An independent reviewer. It has someone available who took no part in the testing and who will check the work. If no independent reviewer is available, the lab should decline the engagement, because it would not be able to release your report.
Agreed scope. Which mobile app, which build, which requirements apply, what is excluded and why, all written down before testing begins.

Who is on the engagement

Role	What they do
Engagement Partner	Accepts the engagement and is accountable for how it is run. Usually your main point of contact. Signs the report.
Engagement Team Lead	Runs the testing day to day and makes sure findings are recorded properly as they are found.
Security Assessors	Do the actual testing and record the evidence. Work only within the assessment types they are individually authorised for.
Quality Control Reviewer	Independent. Took no part in the testing. Re-examines the evidence behind every verdict and can refuse to let the report out.

In short. The reviewer is the part clients least expect and the part that does the most work protecting them. They are not a proofreader. They re-examine the evidence and can overrule the testing team's conclusion in either direction. Nobody in the lab's sales function can overrule them, and their pay cannot depend on your verdict. If you only ask a prospective lab one question about its process, ask who your reviewer will be and how they are independent of the testing team.

How the lab handles your mobile app

Where your app is on a public app store, the lab will normally take the store build rather than one you email over. That is deliberate and it is in your interest: it proves the lab tested what your users actually download, rather than a build prepared for testing. If the store build cannot be used, the reason has to be recorded and the integrity of what you supplied established by hash instead.

A hash is recorded on receipt. The lab takes a cryptographic fingerprint of exactly what it received, so there is never an argument later about which version was tested.
A clean environment is built for you alone. Your engagement gets its own test environment, isolated from other clients' work, and it is destroyed when the engagement closes.
Tools are checked before use. The lab confirms each tool is at the version it has qualified and produces the expected result on a known input. A tool that fails that check is not used.
Your data stays separated. One client's data must not be reachable from another client's engagement. This is a requirement, not a courtesy.

How evidence works, and why you should care

This is the real difference between a laboratory assessment and a consultant's report. For every requirement, the assessor has to record evidence good enough that a different competent assessor could repeat the work and reach the same conclusion. Not a summary, and not a conclusion. The actual input, the action taken and the observed result, captured at the time it happened.

Two consequences follow, and both are in your favour. A lab cannot fail you on a hunch, because if the evidence does not demonstrate that a requirement is unmet, the assessor cannot record a Fail. And a lab cannot pass you on your word: if you tell the assessor a control works and they do not verify it, that is recorded as your statement, not as a validated Pass, and the report has to disclose which requirements were self-attested rather than validated. That protects you too, because nobody can later claim the lab checked something it did not.

How the verdict is reached

Each requirement in scope gets one of three verdicts. There is no partial credit and no overall score that hides the detail.

Verdict	What it means
Pass	The evidence obtained demonstrates the requirement is met for the version tested.
Fail	The evidence obtained demonstrates the requirement is not met.
Inconclusive	The requirement was examined but could not be determined. The report has to say why, and what would be needed to determine it.

Watch the Inconclusive count on your report. Inconclusive is the easy place to park a difficult judgement, and a well-run lab monitors its own rate for exactly that reason. If a large share of your requirements came back Inconclusive, ask why: usually it means the scoping was wrong or something the lab needed was never provided. It is worth knowing when a laboratory is allowed to record Inconclusive, because it may not be used where the evidence would support a Fail.

The independent review

Before anything is released, the reviewer re-examines the engagement: that the build tested is the build received by reference to the recorded hash, that the approved environment and qualified tools were actually used, that every verdict is supported by contemporaneous evidence, that no Inconclusive verdict is standing in for a Fail the evidence would support, that self-attested and excluded requirements are disclosed, that remediation guidance is specific to your application rather than generic advice, and that nobody who was barred or recused took part.

If any of that fails, the reviewer sends it back or withholds the report. That review is itself a record, kept whether or not it changed anything, because a review that found nothing is evidence the control was operating.

What the report has to contain

A MASA report is not a free-form document. Certain elements are mandatory, and the reason each one is there is worth understanding:

Element	Why it is required
A unique report identifier	So the report can be referenced precisely and cannot be confused with another. It also lets you prove which report a customer is looking at.
The laboratory's name and address	So you and anyone you show the report to know exactly who stands behind the conclusions.
Your name and contact details	Identifies who the report was issued to. It also underpins the rule that nobody else may rely on it.
The app identity: package name, build or version identifier, a cryptographic hash, and where the build came from	So there is no possible doubt about what was tested. This is the element that protects you if someone later claims the wrong version was assessed.
The requirement set and its version	The bar you were measured against. Without the version, a conformity statement means very little, because requirement sets get revised.
Dates of receipt, testing and issue	The report describes a moment in time. These dates are what make that explicit rather than implied.
Where the work was performed, including any virtual environment	Assessment work is often done in an environment built for the engagement. Recording it means the conditions are reproducible.
A Pass, Fail or Inconclusive verdict against every requirement	The actual result, at the level of detail that lets you act on it. An overall score would hide exactly the information you need.
Requirements you self-attested that the lab did not validate	So nobody, including a future customer or auditor, can believe the lab verified something it did not. This protects you as much as it protects the lab.
Requirements not evaluated, with the reason	Exclusions have to be visible. A report that quietly omits the requirements you were going to fail is worthless to a reader and dishonest.
Remediation guidance for each failed requirement, specific to your application	Generic advice is not sufficient under the programme rules. You are entitled to guidance that names the component and the change.
A statement of conformity with the programme requirements	A statement about how the assessment itself was conducted. It is separate from the verdict on your application.
The attempt history: initial assessment and every retest, with dates and outcomes	So the report shows the whole story rather than only the final attempt. A reader can see that you failed, fixed and passed, which is a perfectly respectable history.
The name of the person who authorised the report	Somebody has to be accountable for the verdict. This is who.
The laboratory's limitations and disclaimers	What the report does not say. In particular that results apply only to the version tested, that the assessment was not an exhaustive hunt for every vulnerability, and that a Pass is not a guarantee of security.

What happens to the records afterwards

The lab keeps the whole record set, not just the report: the evidence, the verdicts, the environment configuration, the review record, every version of the report and every retest. Retention is typically at least two years after the certificate expires. That exists so that if a question arises later about how a verdict was reached, the answer can actually be produced.

It also means a lab cannot quietly revise history. Every attempt at your assessment, including one that failed, is a retained record with its own report. If a lab suggests it can make a failed attempt disappear, that is a serious problem with that lab.

What you are entitled to ask for

the scope agreement in writing before testing starts;
the name of your Quality Control Reviewer and the basis on which they are independent of the testing team;
the dispute process, in writing, before you need it;
written confirmation that no part of the fee depends on the verdict;
a clear statement of what will be published, what will be sent to ADA, and what consent you need to give;
the lab's retention period for your data, and what is destroyed at the end of the engagement.

A lab that is reluctant to answer any of those in writing is telling you something useful. How to choose an ADA authorised laboratory turns these into questions you can actually ask, and sets out the answers that should end the conversation.

Specific to MASA

A rooted device at the current operating system version. The lab has to be able to test on a device with privileged access, running the latest publicly available OS. If it tested on an older version, the report has to say so, because results can differ.
Both static and dynamic testing. The lab inspects the compiled app itself, and also watches it run. Some requirements can only be checked one way or the other.
Traffic interception. The lab installs its own certificate on the test device and tries to read and modify your app's traffic. If it succeeds where it should not, that is a finding.
Test accounts at more than one state. Logged out, logged in, and where relevant a second account, so the lab can check whether one user can reach another's data.

How it works from your side, step by step

Step 1 — Read the standard first

Download MASVS and read it before you talk to anyone. It is free and it is not long. Teams that skip this step get surprised later, and surprise is expensive.

Step 2 — Do an honest internal check

Go through the requirements against your own app and mark what you think would fail. You will be wrong about some of it, but you will find the obvious problems for nothing.

Step 3 — Fix the obvious problems

Hardcoded keys, data written to unprotected storage, certificate checking disabled during development and never re-enabled, out-of-date libraries. These are common, and much cheaper to fix before a lab is billing you.

Step 4 — Choose an authorised lab

ADA publishes the list. Only use a lab on it. Ask what it costs, how long it takes, how many retests are included and how long you have to use them.

Step 5 — Agree the scope in writing

Which app, which build, which requirements apply, which are excluded and why, and what happens if you disagree with a finding. All of it on paper before testing starts.

Step 6 — Hand over the app and access

Usually the store version plus test accounts. Have the accounts working on day one; missing accounts is the single most common cause of delay.

Step 7 — The lab tests it

Typically one to three weeks of work depending on the size of the app. Expect questions during this period, and answer them quickly, because it shortens everything.

Step 8 — Read the report properly

Look at the Fails, obviously. Then look at the Inconclusive verdicts and ask why, and check the list of requirements recorded as self-attested rather than validated.

Step 9 — Fix and retest

You fix the failures and the lab reassesses. Check how many retests your fee includes and what the deadline is for using them.

Step 10 — Result is submitted

Once you pass, the lab submits the validation and the Play listing note follows. Keep the report; you will be asked for it in security questionnaires for the next year.

Steps 1 to 3 are where almost all of the avoidable cost sits. The four-week preparation plan sets out what to do in each of them before anyone bills you at lab rates.

How long the whole thing takes

Plan for six to twelve weeks from deciding to do it to holding a pass, assuming the app is in reasonable shape. The testing is only part of it. The parts that take longest are usually fixing what was found, and waiting for approvals on your own side.

If your app has never had a security review, add time. A first assessment on an app built without security review in mind finds a lot, and fixing it is real engineering work rather than paperwork.

How often you have to do it again

Every year. MASA validation lasts twelve months and then lapses. That is not bureaucracy, it is the point: a security review of an app that ships every fortnight is out of date almost immediately, so the programme insists on a fresh look annually.

Put the renewal in the calendar two months before expiry, not two weeks. Renewals are usually faster and cheaper than a first assessment, but only if you have kept up. If you have rewritten half the app since last year, treat it as a new assessment.

The mistakes we see most often

Testing the wrong build. The version you send is not the version in the store. Agree which build is tested and record its identifier.
Debug settings left in production. Certificate validation turned off, verbose logging on, debug flags enabled. The single most common category of easily avoided failure.
Secrets in the app package. API keys and credentials compiled into the app, extractable by anyone in minutes. Assume anything shipped inside the app is public.
No test accounts ready. The lab cannot test authentication without working accounts. This delays engagements constantly.
Treating it as a paperwork exercise. It is a technical test. You cannot document your way past a real finding.
Leaving no time to fix. Booking the assessment two weeks before a partner deadline, with no room to remediate and retest.

Frequently Asked Questions

Click any question to expand the answer.

QIs MASA required?

Not by law, and Google does not remove apps that skip it. It becomes effectively required when a customer, partner or platform makes it a condition of doing business, which is increasingly common in finance, health and enterprise software. See the table above for where you probably sit.

QHow does it actually help us?

Three ways. It finds real security problems before an attacker does, which is the main point. It gives you an independent report you can hand to customers instead of filling in the same questionnaire twenty times. And it can put a visible trust signal on your Play Store listing.

QDo we have to do it regularly?

Yes, annually. The validation lasts twelve months. If you let it lapse, the listing note goes and you are back to having no current independent evidence.

QWhat exactly does the lab do that we could not do ourselves?

Technically, you could run most of the same tests. What you cannot do is be independent of yourself. The value is in the combination of a published standard, a tester with no stake in the outcome, an evidence trail that would survive scrutiny, and an independent reviewer inside the lab who can overrule the testing team. See the section above on what the laboratory actually does.

QWhat does it cost?

It varies by lab and by the size and complexity of your app, so we will not quote a figure. Ask two or three authorised labs. When you compare, check what is included: how many retests, how long you have to use them, and whether the price changes if you fail.

QDoes the price depend on whether we pass?

It must not, and if a lab suggests otherwise, walk away. A fee that depends on the outcome destroys the independence that makes the report worth anything. Authorised labs are prohibited from charging outcome-dependent fees, and from linking anyone's pay to the verdicts they record.

QWhat happens if we fail?

Nothing bad happens to your app. There is no public record of a failure and nothing is reported to the store. You get a report listing what failed, you fix it, and the lab reassesses. Failing the first attempt is normal, particularly on a first assessment.

QCan we pick which requirements are tested?

You can agree which requirements genuinely do not apply, with a reason, and that gets recorded. You cannot simply exclude the ones you expect to fail, because anything excluded has to be disclosed in the report and is therefore visible to whoever reads it.

QOur app is small. Is this overkill?

The requirements scale reasonably. A small app with a narrow feature set has fewer applicable requirements and a shorter assessment. If your small app handles money or health data, size is not the relevant question.

QDo we need to give the lab our source code?

Often not. Much of mobile testing works on the compiled app, which the lab can obtain from the store. Some requirements are easier to verify with source access and some labs will ask. Clarify it during scoping.

QWe ship every week. Does the validation break?

The validation refers to the version tested, on the date tested. Shipping updates does not invalidate it, but it does mean the report describes an increasingly old build. That is exactly why renewal is annual.

QIs MASA the same as a penetration test?

Related but not the same. A penetration test asks how far an attacker could get, and is usually open-ended. MASA asks whether your app meets a specific published list of requirements and produces a verdict on each. You may want both, for different reasons. Our mobile application penetration testing is the open-ended kind.

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.

QDoes MASA cover iOS, or only Android?

Both, and Meta Quest as well. The platform is the first digit of every requirement identifier, and the Android and iOS requirement sets run in parallel rather than overlapping. If you ship on two platforms, plan for close to double the work rather than the same work applied twice.

QDoes MASA cover the API our app talks to?

Only as far as the app's own network behaviour goes: whether traffic is properly encrypted, whether the app validates the connection, and whether it handles a tampered response safely. The server side is a separate question, and if your back end is a web application or an API, that is CASA territory rather than MASA. In practice a mobile product usually needs the API tested in its own right as well.

Where to start

Read MASVS. Do an honest internal pass against it. Fix what you already know is wrong. Then talk to an authorised lab with a clear idea of your own position. Teams that arrive prepared spend less and finish faster.

These companion articles go deeper on the parts people ask about most: Inside an ADA Assessment is the full walkthrough of the laboratory process; How to Choose an ADA Authorised Laboratory sets out the questions to ask and the answers that should worry you; and How to Prepare for Your First ADA Assessment is the practical checklist to work through before you engage anybody.

If your product is more than a mobile app, the sibling profiles are covered separately: CASA for web applications and APIs, DASA for desktop applications, and the Cloud App and Config Profile for the infrastructure underneath.

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:

Readiness testing. We test your app against the MASVS requirement set and tell you what would fail, before you pay for a formal validation. Finding out early is much cheaper than failing late. For a mobile product that is mobile application penetration testing, usually alongside API penetration testing for the back end your app talks to.
Fixing what we find. We give you guidance specific to your application, pointing at the actual component and the actual change needed, not a link to a general guideline. Where the cause sits in the source, secure code review is usually the faster route, and where it sits in the design, threat modelling is.
Evidence preparation. We help you assemble the documentation, architecture information and test accounts an authorised lab 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 lab that performs your formal MASA 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 lab and stay out of the way.

Attribution and source

Requirement identifiers, domain names and profile names 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 explanations and remediation advice are our own.

Programme requirements are versioned and they change. 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, and the certification information on the App Defense Alliance website. Where this article describes how a process generally works, that shape is stable. Where it would matter to you whether a number or a version is exactly right, confirm it at the source. How to verify an ADA claim at the source walks through exactly how.