NoFAR Life Sciences Bridging Program

NoFAR Life Sciences Bridging Program

Overview

The official page now presented by the Israel Innovation Authority for this opportunity is the Applied Research in Academia – Applied Research Fund program page. For practical submission, the Hebrew page is where most day-to-day rules are shown, because it contains dates, submission mechanics, and process details.

This is not a generic seed-funding program. It is a knowledge-transfer program that helps academic teams move a project from research-level proof-of-concept into a position where an Israeli company can adopt it for commercial product development.

The useful mental model is simple:

• You have a research result that is too mature for pure basic science publication, but not yet close enough to market.
• The authority can fund the bridge work.
• A company partner can raise your commercialization chance through practical guidance, testing, and later commercialization negotiations.
• You keep your research institution’s knowledge rights, while the partner often gains first-negotiation rights in commercialization discussions.

The page also states that this can run with or without a formal supporting corporation. That changes funding terms and partner obligations, so it matters at the application planning stage.

Quick fit check before reading details

If your answer to all three is “yes,” this can be a good match:

1. Are you in an Israeli academic environment (university, college, research center, hospital, or similar)?
2. Can you show a concrete industrial use case and not only a scientific publication path?
3. Can you define a realistic technical path to a commercialization milestone within 1–3 years?

If you are unsure about any point, this page is still useful, but you should likely spend more time on the “what you need for submission” section before drafting the application.

At-a-glance table

What this opportunity is really for

This is an instrument for teams that are not asking, “Can we discover something new?” but rather, “Can we make this discovery usable in an industrial context with measurable outcomes?”

The English program page describes the incentive as support for applied research that can be taken to the stage where an industrial company adopts it for a commercial product. The Hebrew page uses the same language in operational terms and adds the mechanism: the implementation company (application holder) is expected to validate technology in a relevant environment, create a development path, and report progress regularly.

Practically, you should think of this as a structured pathway with a commercial end point, not a broad science grant:

• It asks for innovation and originality in industrial application.
• It asks for evidence that the result is relevant to Israeli industry and creates economic value.
• It asks for execution capability, not only research ability.

What it offers (beyond plain funding)

1) Grant support with predictable rules

The site states this is grant-like support, not a repayable loan and not tied to royalty payments. The percentages commonly shown are 80% or 90% of approved project budget depending on whether the project is submitted with corporation support.

You should interpret funding as “the authority covers a portion of a validated budget tied to defined milestones.” The practical difference between 80% and 90% matters a lot in budgeting, co-funding, and feasibility scope.

Important: the English and Hebrew pages show different budget cap details in different sections and publication states. Use the current Hebrew submission page as your single source for the final budget numbers, because it is the one tied directly to active forms and submission windows.

2) Commercialization architecture support

The program rewards teams that can show how the partner (if any) improves adoption potential.

The authority describes partner role as:

• professional guidance,
• input into research goals,
• company-side cost contribution (typically around 10% of project cost in the Hebrew description),
• first-negotiation commercial rights at the end.

That is not just wording. In review terms, it is a way for reviewers to reduce risk between “good science” and “real-world deployment.” For teams in biotech and diagnostics, this matters because scale-up and regulatory constraints usually appear only after initial technical feasibility is proven.

3) Optional technical-commercial expertise add-on

The Hebrew content mentions that projects may request support from a commercial technology expert to increase commercialization chance, subject to committee approval and extra documentation steps. This is not automatic. If your team lacks commercialization discipline (pricing assumptions, manufacturing translation plan, user environment validation), this can be a useful lever if and only if the project is accepted for that add-on.

4) A framework for industry readiness

The framework repeatedly points to achieving meaningful milestones in the context of a relevant environment and reaching high practical readiness (TRL-centered framing). For review quality, milestones are better than broad scientific promises.

Eligibility in human language

This program has formal and practical filters. The formal line is: academic institutions/groups in Israel with applied research intent. The practical line is: your application should be written to convince a reviewer that the project can reach practical adoption.

The Hebrew page states the target group includes research institutions from universities, colleges, research institutes, and medical centers.

To avoid common confusion, separate eligibility into three buckets:

1. Entity eligibility Your project lead must be the implementation company of a research institution, not a random industrial company applying on its own.

2. Research maturity The project should be a continuation of prior basic research and have clear industrial application.

3. Project relevance The output should be applicable in Israeli industry and create added economic value.

For teams asking “is it only life sciences?”:

• Life sciences is a core use case, especially with translational technologies.
• The public wording is broader and references applied research generally, so other sectors can be relevant when criteria are met.

Funding and support specifics

The figures below are based on official program pages accessed on the same date this page was updated. Use them as the decision baseline and verify against the latest official Hebrew page before you finalize any proposal budget.

The English page also lists detailed consortium-based caps for different configurations and can show different absolute ceilings for single/two/three institutions. This inconsistency suggests periodic updates to tables. For this reason, treat any raw number as “directional until you confirm in the current application window.”

Also noted in official content:

• No royalty payment obligation for this support.
• In exceptional cases, extended support may be reduced percentage in a third year (as per English page language).
• Pharmaceutical preliminary-year requests are mentioned as special consideration in the English page.

What this means for budget planning

Write every expense as part of a milestone chain:

• what is expected at milestone 1,
• what proof indicates progress,
• what changes unlock milestone 2,
• what partner resources are needed at each stage.

If a reviewer cannot connect one line of budget to clear technical or commercial progress, that budget line becomes your first weakness.

The application process in plain steps

Step 1: Decide the program version and deadlines

This is a rolling track, but not always “open forever.” The Hebrew page shows publication of next-date windows, for example:

• 31/05/2026
• 08/07/2026
• 11/08/2026
• 09/09/2026
• 02/11/2026

Those dates change by cycle, so treat this list as “recently published windows,” not a fixed annual calendar.

Step 2: Confirm who submits and who owns the application

The submission is carried out only by the implementation company representing the research institution. Industrial companies that are interested in collaboration should approach the implementation company directly.

That is a key structural constraint. If your project currently has only a corporation lead and no formal academic implementation company, you likely need to reframe ownership before submission.

Step 3: Read the program terms section by section

Before writing narrative copy, read these mandatory operational sections:

• Who is eligible,
• What funding rates apply with/without corporation support,
• Requirements and technical conditions,
• evaluation criteria,
• and document submission requirements.

Do this because details can shift between sections and can affect your file structure.

Step 4: Prepare the application package

You submit through the Authority portal under the investment form workflow. The official process says you need:

• registration/login to personal area,
• completing the electronic investment application form,
• uploading required forms and attachments in the attachment section.

Be aware of file constraints: password-protected documents and illegal file-name symbols are rejected (# % & * : < > ? / { | }).

Step 5: Manage technical compliance

Use this order:

1. complete application narrative,
2. align with forms required in the same section,
3. then run file name and format validation,
4. then run final legal/institutional checks.

The authority specifically accepts only complete and valid submissions; late or invalid files are rejected.

Timeline and deadline reality check

There are two layers of schedule:

• Submission window layer: rolling windows published regularly.
• Committee response layer: responses usually tied to date bands.

The Hebrew page explains the practical consequence:

• submissions go by window.
• responses are grouped by submission date windows.
• the noon cutoff is strict; a late submission often gets returned.
• technical support has a cutoff too.

A practical planning sequence that has worked for teams:

• Day 1–7: draft project narrative and partner role.
• Day 8–14: build milestone timeline and TRL trajectory.
• Day 15–21: create budget tied to work packages.
• Day 22–24: map required attachments against the list and naming rules.
• Day 25+: internal dry run and final submission buffer (no last-minute panic).

Even if this sounds slow, teams that leave everything to the last two days usually fail on completeness.

Required materials and evidence (what to prepare)

The exact attachment names can change by cycle and are maintained in the application environment. At minimum, prepare these categories as a working set:

• Project narrative explaining applied relevance.
• Clear TRL and milestone plan.
• Technical baseline and prior research context.
• Budget by work package with rationale.
• Team and execution model, including governance.
• Corporate support and role description (if applicable).
• Ownership and commercialization treatment.
• Risk and compliance assumptions.
• Legal sign-off material from the institution and collaborators.

The key is not only writing them down, but matching every claim to one of the required form categories. If not, your submission can be seen as fragmented.

Who should apply: practical fit guidance for normal teams

Use this scorecard with yes/no values. A “yes” to at least 8 out of 12 is a strong starting signal.

• We are an Israeli research institution or implementation company connected to one.
• The research is a continuation of prior work and not purely exploratory.
• We can name one industrial pain point the technology addresses.
• The outcome can be tested in conditions that a company would consider commercial.
• We can explain TRL milestones clearly (especially TRL 3, 4, 5 pathway).
• We can define who owns execution decisions.
• We can set realistic cost assumptions.
• A partner role is either already identified or can be added in writing.
• We can produce a two-line project story in non-technical language understandable to commercial reviewers.
• We accept that no royalty payment exists, but compliance obligations still apply.
• We can support semi-annual reporting and milestone-based governance.
• We understand there can be call-specific windows and technical conditions.

If you score below five, the opportunity is usually too early for this instrument.

How to decide whether this is worth your time

The key cost of applying is not financial; it is team time and internal coordination.

Ask these in your first planning meeting:

• Can we show industrial fit in one paragraph?
• Can we show a realistic TRL progression in one roadmap?
• Can we confirm ownership and signing authority across institutions and partner entities?
• Can we show a budget that can be audited by reviewers?

If any answer is “not yet,” you should spend at least one month cleaning this before applying. If you apply now and your answer is unclear, the most common outcome is a complete but weak submission that fails in review or gets delayed.

How to make your application easier to approve

Emphasize commercialization pathway, not only innovation

Do not start with novelty. Start with adoption. Reviewers already expect originality. They score stronger if they see:

• clear user or process pain point,
• realistic scale path,
• measurable evidence that company collaboration is meaningful.

Make milestone statements testable

Replace vague language (“advance platform,” “improve readiness”) with measurable outcomes:

• “by month 4, establish pilot in industry-like conditions with defined acceptance criteria,”
• “by month 6, complete independent validation dataset with defined sensitivity/specificity threshold,”
• “by month 9, submit commercialization handover package.”

Build partner utility explicitly

Whether your project has a partner or not, include this question:

• What does the partner add that your laboratory cannot do alone?

If the answer is only “funding,” your partner is probably too weak strategically.

Prepare for the technical inspection step

The Hebrew page refers to a professional inspection visit in some cases. That means your practical implementation plan, data quality, and team capability need to be credible before approval.

Common mistakes seen in poor submissions

1. Failing to submit through the correct implementation company

• Corrective action: make the implementation company the official submitter and document roles.

2. Treating the application as an academic research paper

• Corrective action: write it as a commercialization program with market-facing milestones.

3. Missing or weak commercialization ownership logic

• Corrective action: define who leads commercialization negotiation preparation.

4. Budget lines without link to milestones

• Corrective action: attach each budget line to a milestone and output.

5. Ignoring file rules and legal naming constraints

• Corrective action: run a file audit pass before submission.

6. Assuming partner support is optional and therefore insignificant

• Corrective action: choose with intention. If you include a partner, make partner deliverables explicit and measurable.

7. Not accounting for the noon deadline and window-based review process

• Corrective action: set internal deadlines 48 hours earlier than official cutoff.

FAQ

Is this definitely the same as a “NoFAR” program?

The public path now appears under Applied Research in Academia naming on official pages. For this reason, many older references use legacy labels while operations use this consolidated route.

Is it only for life sciences?

No. Life sciences teams are important examples, but the official language is broader (applied research with industrial feasibility in Israel).

Do I need a supporting company from day one?

No. You can submit without one. A supported track is available and often viewed as stronger when commercialization pathway is clear.

What funding rate should I expect?

As publicly shown, without support the rate can be around 80%, and with support around 90%. Confirm in current cycle tables.

Who owns the knowledge?

The application materials clearly state knowledge/knowledge-based commercialization rights remain with the applying research institution, while partner rights involve negotiation priority.

Can this support last more than 12 months?

Yes, the program references support over multiple years (up to three in official text), with reduced support possibilities in exceptional circumstances.

How are late filings handled?

The process is strict. Submissions after the published noon cutoff or incomplete submissions are returned.

Decision support: should your life-sciences project apply now?

Use this practical checklist in one team meeting:

• Is the project closer to TRL3/4/5 than TRL1/2?
• Can we make a case in the language of industrial benefit?
• Can we submit all required documents correctly on time?
• Can we show what “success” means in 6, 12, and 24 months?

If at least three of four are still “no,” it is usually better to prepare and apply in a later window than to submit incomplete materials.

For teams in biotech who already have a near-industrial partner, this program is usually one of the better structured pathways for early-stage technology with translational intent.

What changes after acceptance

Award is not the end of work. You then face:

• semi-annual progress reporting,
• evidence-driven project updates,
• continued commercialization planning,
• potential technical review and adjustments,
• clear communication with partner and authority.

Teams often improve outcomes when they create a reporting calendar during week one of approval, not after the first progress report is due.

Official links and next steps

• Applied Research in Academia – Applied Research Fund (English)
• מסלול מחקר יישומי באקדמיה – קרן המחקר היישומי (Hebrew, official process and dates)
• My Innovation Israel personal portal (application entry)
• Calls page from the English version (if available)

If you want to turn this into a submission-ready checklist, begin with these three pages today:

1. read the English program summary,
2. open the Hebrew process page and copy the latest submission windows,
3. confirm current required attachments before writing your final budget.

At-a-Glance Snapshot

What this opportunity is really designed to do

People often think this is a “science grant,” but that understates its design. It is really an industry-alignment instrument inside the innovation ecosystem.

From the official description, the program is intended to:

• move applied research with realistic industrial relevance forward,
• connect it to an industrial companion (optional but often stronger for commercialization), and
• produce projects that can reach meaningful negotiation or commercialization gates.

The practical logic is: if your lab can make the science, and an industrial partner can make the product, this program helps you pay for the bridge.

It does not automatically produce a startup in every case. It produces a defined research-to-application pathway with stronger probability of commercialization, and that is the main output judges are trying to fund.

What it offers (in concrete terms)

1) Grant support tied to budget and milestones

The program provides support as a percentage of an approved budget. The public materials specify tracks with and without supporting industrial company, and rates in the high-coverage band (commonly quoted in official pages as around 80% to 90%).

What matters for you:

• Build your costs by milestone, not by wish list.
• Show what each expense leads to (validation, prototype improvement, quality checks, partner integration).
• Do not ask for money for work that does not reduce commercialization risk.

2) Commercialization mechanics, not only funding

A core design element is the possibility of adding a supporting company and aligning project goals with real-world deployment constraints. If your project is too abstract, a company co-pilot is often the difference between “promising technology” and “investable technology path.”

In this model, the partner is expected to:

• advise on practical goals,
• participate in technology refinement, and
• contribute to commercialization orientation.

The authority language also supports the idea that knowledge generated remains with the research institution while the partner typically gains first-negotiation rights in commercialization discussion.

3) Structured execution expectations

This program has a TRL emphasis and process discipline. You should not submit a broad roadmap with fuzzy steps. Your submission should describe what technical readiness you will reach and when.

A practical example of this framing is not “we will improve a platform,” but “we will deliver TRL-3 readiness by quarter two, demonstrate a validated assay workflow in industry-relevant conditions by quarter three, and produce commercialization data for partner-side review by quarter six.”

Who should apply

Use this short decision test before you start a full draft.

You are likely a good fit if all of these are true:

• You are based at an Israeli academic institution or represent an application team linked to one.
• Your project is already beyond pure hypothesis testing and is at a stage where engineering or validation work can begin.
• There is a plausible industrial use case with either a committed or near-committed partner.
• You can define output success in measurable form (technology readiness, validation result, user/process gain).
• You are prepared for a compliance-heavy, application-centric process.

You may want to pause and re-scope if:

• your output is purely scientific publishing and not implementation oriented,
• you cannot clearly state who benefits in industry,
• your team has not agreed who is responsible for project execution, or
• your budget is not linked to actual milestones.

For life-sciences teams, this is usually a strong match when the project involves devices, diagnostics, preclinical methods, translational bioinformatics, molecular tools, or therapeutic process research with a defined industrial partner pathway.

Eligibility translated into plain-language checks

The official pages target:

• research groups from universities, colleges, research centers, and medical institutions in Israel,
• projects with original innovation and industrial usability,
• and teams that can demonstrate commercialization potential.

The check in your working draft should answer three practical points:

1. Who is applying?

• Is there a single accountable application entity (application company) from the research side?

2. What technology gap is being filled?

• Is the problem industrially relevant and does it solve a real bottleneck?

3. How is industrial value created?

• Does the project lead to a tangible downstream path?

Why the “old NoFAR” confusion happens (and how to handle it)

The opportunity ecosystem has undergone naming and program-structure evolution. What was publicly presented in older references as specific NoFAR life-sciences variants is now presented more clearly under an active applied-research family page.

This is not unusual in public grant systems. The practical lesson: use the active official page as source of truth for application conditions, then map legacy understanding to that process.

If someone on your team says “this is exactly the old NoFAR file,” thank them for the historical memory but run your submission on the active path.

Application process (step by step)

Step 1: Read both the English and Hebrew references

The English page is useful for program framing. The Hebrew program page carries operational submission details, including partner filing expectations and the current route through the authority portal.

Step 2: Decide your submission track

Choose one at the start:

• Academic track without a supporting corporation (lower matched share)
• Academic track with supporting corporation (higher support percentage but more structured partner obligations)

Write your budget and timeline in one pass according to the selected track.

Step 3: Build a clean submission architecture

• Define a single-page problem statement.
• Define a technical hypothesis that can be tested in your stated timeframe.
• Define TRL-targeted milestones.
• Define partner roles (advisor, developer, evaluator, future licensee).
• Define ownership and commercialization rights in clear plain text.

Step 4: Prepare required documents before narrative polishing

The Authority process requires a complete online submission set. Prepare attachments first and then write around them. This avoids the common failure where the budget text says “yes” but the upload package says “no.”

Keep filename rules in mind for uploaded files.

Step 5: Submit on time with all forms complete

The process emphasizes complete, valid submissions. Submissions that are late, incomplete, or technically invalid are often returned.

Timeline and deadline expectations

This is the most confusing part for teams accustomed to one fixed deadline.

• The program is framed as an ongoing annual track.
• Specific submission rounds are published.
• The Hebrew page includes a current next-submission date and indicates that call windows are active.

So your planning should be continuous, not one-and-done:

• build draft by a fixed internal date,
• run peer review by a second date,
• submit before the portal cutoff after attachments are validated.

If your project is not ready for a current window, do not delay to the point where only a late final edit remains. It is better to withdraw and submit in the next valid window than to submit incomplete materials.

Required materials and expected contents

Use the Authority guidance and current submission list as the canonical checklist. As a practical preparation template, prepare:

• project summary and technical rationale,
• team profile and management responsibilities,
• budget table with milestone-linked cost lines,
• industrial relevance and TRL plan,
• governance and ownership statements,
• partner involvement statement where relevant,
• and any forms required in the official “add attachments” section.

Before submission, review this list with one person who has final responsibility for validity. Ask:

• does this file prove our project is feasible,
• does it prove our project is industrially relevant,
• does it prove our team can execute.

Budget planning guidance that helps reviewers trust you

Most rejections are not caused by “bad ideas” but by unconvincing execution logic.

Recommended budget habits

• Use a milestone-linked structure.
• Separate direct project costs, partner costs, and reporting costs.
• Avoid budget inflation; inflated lines often trigger skepticism.
• Keep partner contribution logic explicit if you have one.
• Include contingencies only where technically justified.

The program does not reward random precision or complexity in cost wording. It rewards clarity: if a reviewer can connect each amount to a milestone that increases commercialization probability, your chance improves.

What can go wrong with budgets

• claiming very high support percentages without matching deliverables,
• mixing exploratory research with mandatory commercial work but labeling everything together,
• attaching a budget that has no clear TRL-linked output,
• asking for costs that are unrelated to the project goal.

Common mistakes and practical fixes

Mistake: Using old program wording without current mapping

Fix: Use current eligibility and submission language from the active pages. Include only terminology that you can justify in the current framework.

Mistake: Treating the process as an academic application

Fix: frame the submission as a commercialization pathway. Show expected industrial use and partner value.

Mistake: Underbuilding partner role

Fix: define in the project what the partner contributes (input, testing, data, manufacturing context, regulatory input).

Mistake: Relying on late revisions

Fix: lock the first draft early, then do only targeted improvement passes.

Mistake: Weak project management evidence

Fix: identify owners, define meeting cadence, and keep issue logs.

How to evaluate whether it is worth your time

A practical “go/no-go” model:

• If you can map your idea to an industrial use case in one paragraph, go.
• If you can create a TRL-based milestone plan in three lines, go.
• If your team can submit with confidence before the cutoff, go.
• If you are still debating the basic ownership or partner logic after a full day of prep, pause and clarify first.

This is not a program for loosely defined research ideas. It is for teams that are ready to build a credible bridge between academic output and applied industrial value.

What to do after acceptance

A successful selection is not the finish line. Most teams underestimate post-award obligations:

• regular progress reporting,
• strict budget tracking,
• partner communication and commercialization follow-up,
• evidence-based adjustments if milestones are missed,
• and preparation for commercialization agreement discussions.

Set up these structures before you receive approval so your team can activate instantly.

Frequently asked questions

Is this still a NoFAR program?

Publicly, the current active structure is presented through the Applied Research in Academia route rather than the older NoFAR-branded path in English.

Is it only for life sciences?

Life sciences teams are strongly relevant, but the pathway is not limited strictly to one subsector. What matters is applied feasibility and industrial relevance.

What percentage can we realistically expect?

The official pages describe different support rates. In practical terms, higher matching is associated with an approved supporting company track, while non-supported tracks have lower percentages.

Is a company partner required?

No. But if your commercialization pathway is weak, the partner-supported format usually improves selection strength.

Do I lose intellectual property?

The official text emphasizes that rights to generated knowledge remain with the application-side research institution. This is a key condition to keep in mind in partner negotiations.

What should I do if we miss the noon submission time?

The process pages are explicit about time-sensitive submission quality. Late or incomplete submissions are usually rejected, so build an internal internal deadline at least 1–2 days earlier.

Practical preparation checklist

1. Confirm active program pages and links.
2. Define problem statement and industrial use case.
3. Build TRL-linked milestones.
4. Draft budget for measurable outcomes.
5. Prepare attachments in final naming format.
6. Run a dry-run submission with checklists.
7. Submit before the official cutoff with buffer time.

Common risks teams miss

• assuming funding rate is fixed and uniform across all tracks,
• underestimating required partner documentation,
• using scientific language that hides practical outcomes,
• and forgetting that review quality favors execution clarity over concept ambition.

Official links and next actions

• Applied Research in Academia – Applied Research Fund (official English page)
• Applied Research in Academia – Hebrew program page (submission and requirements)
• My Innovation Israel (submission portal)

If you are a research group lead, use the next two weeks to convert your scientific concept into one project story with defined milestones and a clear partner plan. That conversion is usually the real difference between approval and “almost-ready.”